Ситуация, когда основная база данных (особенно скульная база разработчика) оказывается безвозвратно затертой, является критической. Однако, если на компьютере разработчика сохранился локальный кэш конфигурации, шансы на спасение значительной части программного кода велики. В данной статье мы разберем, как устроены файлы ConfigCacheStorage, ConfigCacheVersions, RuntimeCacheStorage и RuntimeCacheVersions, и как с их помощью восстановить доработки.
Прежде чем приступать к активным действиям, проанализируем, что представляет собой ConfigCacheStorage. Вопреки частому заблуждению, это не файл базы данных формата .1CD. Именно поэтому стандартные утилиты типа Tool_1CD или cnvdbfl.exe выдают ошибку о неверной сигнатуре или неподдерживаемой версии.
На самом деле, ConfigCacheStorage — это бинарное хранилище (Document Storage), структура которого напоминает внутреннее устройство .cf файла, но без заголовков таблиц. Это набор потоков данных, в которых 1С хранит сериализованные объекты метаданных и тексты модулей в сжатом виде. По размеру этот файл обычно составляет около 1/3 от полноценного .cf, так как в нем отсутствуют структуры таблиц БД, но зато почти всегда присутствуют тексты всех измененных модулей и описания форм.
Поскольку 1С использует алгоритм Deflate (Zlib) для сжатия данных внутри хранилища, мы можем попытаться извлечь блоки данных напрямую. Рассмотрим алгоритм действий:
ConfigCacheStorage в любом HEX-редакторе.78 9C — стандартное сжатие;78 DA — максимальное сжатие;78 01 — минимальное сжатие.Для автоматизации процесса рекомендуется использовать скрипты на языке Python или специализированные утилиты, которые проходят по всему файлу, находят каждый блок, начинающийся с 78 9C, и пытаются его распаковать. Результатом работы такого скрипта станут тысячи мелких файлов, среди которых поиском по тексту можно найти нужные фрагменты кода Процедура или Функция.
Разберем еще один важный источник данных, который часто забывают. По пути C:\Users\ИмяПользователя\AppData\Local\1C\1cv8\идентификатор_базы\идентификатор_пользователя\vrs-cache\ часто находится файл cache.1cd.
В отличие от основного хранилища, этот файл часто является полноценной базой 1CD (или SQLite в последних версиях). Проанализируем его с помощью Tool_1CD. В нем хранятся потоки исполняемых модулей. Если база запускалась незадолго до инцидента, там могут сохраниться тексты модулей, которые компилировались платформой для исполнения. Хотя этот кэш обычно меньше по объему, из него проще извлечь читаемые данные программным способом.
Этот метод считается экспериментальным и срабатывает не всегда, но его стоит попробовать. Идея заключается в том, чтобы заставить конфигуратор «подумать», что данные в кэше новее, чем в базе. Рассмотрим шаги:
.cf, с которого начиналась разработка (базовая версия до внесения правок).1cv8.exe через диспетчер задач, чтобы 1С не успела очистить временные файлы.ConfigCacheStorage и ConfigCacheVersions на те, что остались от удаленной базы.Внимание: Платформа часто проверяет GUID конфигурации. Если GUID в кэше не совпадет с идентификатором в новой базе, 1С просто обнулит кэш. Чтобы этого избежать, нужно использовать HEX-редактор для корректировки идентификаторов в заголовке файла, что требует глубоких знаний структуры ConfigStorage.
Если нам удалось извлечь потоки из кэша, мы можем попробовать внедрить их в существующий .cf. Для этого проанализируем структуру обычного файла конфигурации, разобранного через v8unpack.
Посмотрим на пример структуры после разбора:
v8unpack.exe -parse base.cf base_unpacked
Внутри мы увидим файл root, который ссылается на другие идентификаторы. Нам необходимо:
ConfigCacheStorage.base_unpacked на наши восстановленные файлы..cf обратно.Для распаковки отдельных бинарных блоков можно использовать простую функцию на встроенном языке (если у вас есть внешняя компонента для работы с Zlib) или Python-скрипт:
import zlib
def decompress_block(input_file, output_file):
with open(input_file, 'rb') as f:
data = f.read()
# Ищем заголовок 78 9C и распаковываем
decompressed = zlib.decompress(data)
with open(output_file, 'wb') as out:
out.write(decompressed)
Проанализировав ситуацию, можно сделать вывод: полное автоматическое восстановление .cf из ConfigCacheStorage крайне затруднительно из-за потери связей метаданных. Однако тексты модулей (Общие модули, Модули объектов) вытаскиваются практически всегда.
Алгоритм спасения данных:
78 9C для извлечения сжатых данных.v8Reader или модифицированный v8unpack для просмотра бинарных данных.cache.1cd из папки vrs-cache, так как они легче поддаются разбору стандартными средствами работы с 1CD.Помните, что ConfigCacheStorage — это ваш последний рубеж. Если админы затерли базу, а хранилище конфигурации не использовалось, этот файл — единственный способ не переписывать проект с нуля.