Первый способ поиска на компьютере
Первый способ самый быстрый и поэтому используется по умолчанию.
В этом случае обновлятор ищет в папках (указанных в настройках программы как шаблоны 1С) файлы 1cv8.cfu, а решение о выстраивании цепочки обновления принимает на основании лежащих рядом (в той же папке) текстовых файлов:
- 1cv8.mft (манифест обновления; в нём указаны название, разработчик и версия конфигурации)
- UpdInfo.txt или, созданный конфигуратором при поиске, 1cv8.cuc (в нём содержится список конфигураций, к которым применимо это обновление)
Текстовые файлы имеют небольшой размер, поэтому их разбор происходит быстро. Но зачастую файлы 1cv8.mft и UpdInfo.txt в папке с обновлением отсутствуют или содержат недостоверную информацию. В этом случае нужно воспользоваться вторым способом поиска.
Второй способ поиска на компьютере
Этот способ включается в свойствах конкретной базы (или сразу для группы баз ):
Этот способ самый точный. Он ищет в указанных в настройках папках с шаблонами любые файлы с расширениями ".cfu" и ".cf" (и ему всё-равно как они называются и как расположены). Далее он делает разбор этих файлов, чтобы достоверно узнать: название, разработчика и версию конфигурации. А в случае с файлами с расширением ".cfu" он также узнаёт к каким конфигурациям применимо это обновление.
Таким образом всю информацию, которую обновлятор получает при первом способе из файлов 1cv8.mft и UpdInfo.txt, при втором способе он читает напрямую из файла с обновлением (или конфигурацией).
Это значит, что сами файлы с обновлением могут называться как угодно и могут быть расположены также как угодно (вплоть до того, что все файлы cfu лежат в одной папке).
Раз этот способ поиска так хорош, почему он не включен по умолчанию? Потому что в первый раз его запуск занимает много времени, когда обновлятор по честному прочитывает все найденные файлы с расширением ".cf" и ".cfu" (а они могут иметь размер в сотни мегабайт), а затем создаёт кэш с необходимой информацией там же в папке с найденным файлом.
Куда и в каком виде обновлятор записывает кэш (небольшой бинарный файл с необходимой информацией о найденном файле с обновлением)? Файл с кэшем обновлятор пишет в ту же самую папку, где лежит файл с обновлением, а имя файла с кэшем формируется как "{filename.ext}.updater1c". У файла с кэшем (он занимает менее 1 кб) также выставляется атрибут, делающий его скрытым. Если запись новых файлов в папку с обновлением недоступна - обновлятор записывает эти файлы в свою внутреннюю папку "Data/Cache/Templates".
У второго поиска есть также некоторые особенности.
Для работы опций (в случае их включения) "Применять обновление не раньше чем через X дней после их выхода" и "Поиск минимальной версии платформы" по-прежнему используется информация из текстовых файлов внутри папки с обновлением. Это связано с тем, что непосредственно из файлов CF и CFU эту информацию получить нельзя.
Для опции "При возможности обновлять из *.cf" несколько по другому начинает работать вариант "последовательно":
- Если при первом способе поиска обновлятор в этом случае стремится построить из cf кратчайшую цепочку, основываясь на информации в лежащем в папке с обновлением файле UpdInfo.txt (там указано для каких версий конфигураций применимо обновление).
- То при втором способе поиска обновлятор строит максимально последовательную цепочку из найденных cf, так как в этом случае он опирается исключительно на информацию, которую он может прочитать из самого файла cf.
