Переход на новые версии платформы 1С:Предприятие часто сопровождается не только исправлением старых ошибок, но и появлением новых нюансов в работе привычных механизмов. Одной из таких проблем стал сбой в работе функции НайтиФайлы() при использовании релиза 8.3.18.1289. Проблема чаще всего проявляется при работе с сетевыми каталогами (UNC-путями) и в регламентных заданиях на стороне сервера. В этой статье мы подробно проанализируем причины такого поведения и разберем способы восстановления работоспособности обмена файлами.
Рассмотрим предысторию появления этого релиза. Версия 8.3.18.1289 была выпущена как экстренное исправление ошибки идентификации пользователей («Пользователь ИБ не обнаружен»). Однако вместе с исправлением в платформу были внесены изменения в библиотеки работы с файловой системой и механизмы взаимодействия с сетевыми редиректорами Windows. Выясним основные факторы, которые влияют на результат поиска:
НайтиФайлы() претерпел внутренние изменения, направленные на унификацию работы в разных операционных системах, что повлияло на привычную логику в Windows.Проанализируем синтакс-помощник и рекомендации опытных разработчиков. Одним из первых шагов при возникновении проблем с поиском файлов по сетевому адресу должна стать проверка формата строки пути. В версии 8.3.18 платформа стала требовать более явного указания структуры каталога.
Посмотрим на пример кода, который помогает нормализовать путь перед вызовом функции:
// Пример нормализации пути для сетевого каталога
ПутьККаталогу = "\\192.168.1.7\TempLocal";
// 1. Заменяем обратные слеши на прямые, если этого требует логика платформы
// Хотя для Windows UNC-путей это не всегда обязательно, 8.3.18 стала стабильнее
// работать именно с прямыми слешами в некоторых контекстах
ПутьККаталогу = СтрЗаменить(ПутьККаталогу, "\", "/");
// 2. Обязательно добавляем закрывающий слеш в конце
Если Прав(ПутьККаталогу, 1) <> "/" Тогда
ПутьККаталогу = ПутьККаталогу + "/";
КонецЕсли;
МассивФайлов = НайтиФайлы(ПутьККаталогу, "*.xml");
Важный момент: Обратите внимание на наличие закрывающего слеша в конце пути. В версии 8.3.18 отсутствие финального разделителя часто приводит к тому, что платформа интерпретирует последнюю часть пути не как каталог, а как префикс имени файла, из-за чего поиск возвращает пустой массив.
Разберем ситуацию, когда код остается неизменным, но файлы перестают «видеться» после обновления. Если база работает в клиент-серверном варианте, выполнение кода происходит на стороне сервера под учетной записью службы 1C:Enterprise Server.
Часто служба запускается под LocalService или NetworkService. В релизе 8.3.18 были замечены изменения в работе с сетевым окружением: платформа может блокировать анонимные запросы к сетевым папкам. Проанализируем шаги по исправлению прав:
LocalSystem или LocalService, попробуйте временно изменить пользователя службы на доменную учетную запись, которая имеет гарантированный доступ к сетевому ресурсу \\192.168.1.7\TempLocal.Для того чтобы понять, видит ли платформа каталог в принципе, рекомендуется использовать объект Файл. Это поможет локализовать ошибку: проблема именно в маске поиска функции НайтиФайлы() или в отсутствии доступа к самому каталогу. Рассмотрим диагностический код:
ПроверяемыйКаталог = "\\192.168.1.7\TempLocal\";
ОбъектФайл = Новый Файл(ПроверяемыйКаталог);
Если ОбъектФайл.Существует() Тогда
Сообщить("Платформа видит каталог. Проблема в параметрах поиска или маске.");
Если ОбъектФайл.ЭтоКаталог() Тогда
Сообщить("Это действительно каталог.");
КонецЕсли;
Иначе
Сообщить("Платформа НЕ видит путь. Проблема в правах доступа службы сервера или синтаксисе пути.");
КонецЕсли;
Если метод Существует() возвращает Ложь, то никакие манипуляции с маской (например, "*.xml") не помогут — необходимо решать вопрос с сетевой доступностью ресурса для конкретного релиза платформы.
В платформе 8.3.18 было обновлено описание методов НачатьПоискФайлов и НайтиФайлыАсинх. Если ваша конфигурация находится на высоком режиме совместимости, попробуйте перевести критичные участки кода на асинхронные вызовы. В некоторых случаях это позволяет избежать блокировок, связанных с ожиданием ответа от сетевой файловой системы (SMB-таймауты).
Также стоит проверить установленный режим совместимости в свойствах конфигурации. Если он ниже 8.3.15, переход на платформу 8.3.18 может вызывать непредсказуемое поведение методов глобального контекста из-за разницы в архитектуре работы с внешними ресурсами.
Подводя итог, можно сказать, что переход на 8.3.18.1289 требует более аккуратного обращения с путями. Краткий чек-лист для исправления:
\ на прямые /.Использование вышеперечисленных методов позволяет обойти технические ограничения релиза 8.3.18.1289 и восстановить стабильную работу обмена файлами в автоматизированных системах.