При администрировании и поддержке большого количества информационных баз 1С часто возникает необходимость выполнения «веерного» обновления. Системные администраторы и программисты запускают процесс обновления параллельно в нескольких конфигураторах, используя один и тот же файл обновления (с расширением .cfu или .cf). Однако в этот момент можно столкнуться с неприятной ошибкой совместного доступа к файлу, после чего платформа предлагает перезапустить процесс.
В этой статье мы подробно разберем, почему возникает данная проблема, как именно платформа 1С взаимодействует с файлами обновлений на уровне операционной системы, и рассмотрим практические методы обхода этой блокировки.
Проанализируем техническую сторону процесса. Когда мы инициируем обновление конфигурации через Конфигуратор, платформа не просто последовательно считывает данные из файла. Она выполняет целый ряд дисковых операций:
Temp.Если мы запускаем обновление во второй базе в тот момент, когда первый Конфигуратор еще выполняет распаковку и держит файл заблокированным, операционная система возвращает ошибку совместного доступа (в терминах Windows — «Sharing violation», код ошибки 32).
Выясним распространенное заблуждение: помогает ли установка атрибута «Только для чтения» на уровне файловой системы избежать этой блокировки?
Нет, это не решит проблему. Когда Конфигуратор открывает файл обновления, его внутренний программный код запрашивает у операционной системы дескриптор файла с определенными флагами совместного доступа (через функцию API Windows CreateFile). Если первый экземпляр Конфигуратора открывает файл в монопольном режиме без флага совместного чтения FILE_SHARE_READ, операционная система отклонит любой другой запрос на открытие от второго Конфигуратора. Наличие атрибута «Только для чтения» никак не влияет на то, что первый процесс уже монопольно захватил права на работу с файлом.
Рассмотрим подробнее эффективные варианты обхода ошибки совместного доступа при параллельной работе.
Поскольку монопольный захват файла длится только на этапе инициализации (обычно от 5 до 20 секунд в зависимости от производительности дисковой подсистемы), нам не обязательно сразу делать физические копии файлов. Мы можем применить ручную задержку:
Если нам необходимо обновить десятки баз одновременно без ожидания, самым надежным решением будет создание копий файла обновления. Мы можем сделать несколько дубликатов файла 1cv8.cfu (например, 1cv8_1.cfu, 1cv8_2.cfu и так далее) или скопировать их в разные временные папки и указать каждому Конфигуратору свой собственный путь.
Очень часто проблему усугубляет антивирусное ПО или сетевое размещение файлов. Если файл обновления лежит в сетевой папке, протоколы SMB (особенно механизмы *Opportunistic Locks / Oplocks*) могут удерживать блокировку файла значительно дольше.
Для оптимизации процесса выполним следующие шаги:
.cfu или .cf на быстрый локальный SSD-диск сервера, где запущены Конфигураторы..cf, .cfu, .1cd, .tmp) и рабочие каталоги (включая временную папку пользователя AppData\Local\Temp) в список исключений антивируса на сервере, чтобы избежать параллельного сканирования файлов в момент их открытия Конфигуратором.Для системных администраторов, которые ценят свое время, ручной запуск нескольких Конфигураторов малоэффективен. Проанализируем сценарий автоматизации пакетного обновления баз с использованием PowerShell. Мы можем запускать обновления последовательно или с контролируемой задержкой, чтобы исключить конфликты блокировок.
Разберем пример простого скрипта, автоматизирующего этот процесс:
# Массив путей к информационным базам 1С
$bases = @("C:\1Bases\Base1", "C:\1Bases\Base2", "C:\1Bases\Base3")
# Путь к общему файлу обновления
$updateFile = "C:\1C_Updates\1cv8.cfu"
foreach ($base in $bases) {
Write-Host "Запуск обновления для базы: $base"
# Запуск Конфигуратора в пакетном режиме для обновления конфигурации
Start-Process "C:\Program Files\1cv8\common\1cestart.exe" -ArgumentList "DESIGNER /F `"$base`" /UpdateCfg `"$updateFile`" /UpdateDBCfg" -Wait
# Небольшая пауза перед переходом к следующей базе, чтобы гарантировать освобождение ресурсов
Start-Sleep -Seconds 15
}
В данном скрипте мы используем параметры запуска Конфигуратора /UpdateCfg для наката файла обновления и /UpdateDBCfg для обновления конфигурации базы данных. Использование командлета Start-Sleep гарантирует, что процессы не будут конфликтовать за доступ к файлу .cfu.
Таким образом, понимание механизмов блокировки файлов платформой 1С позволяет нам легко обходить подобные системные ошибки и эффективно настраивать процессы администрирования.