И снова попытки лечения битого файла 1Cv8.1CD... #603067

Тут на форуме уже подымался аналогичный вопрос. Может кто-то знает формат файла? Очень нужно попытаться вытащить данные. На описан формат, но у меня что-то не срастается все в единое - что-то не выходит получить смещение к нужной информации.

размер архива?

В описании таблицы в строке {"Files",118,119,96} - индексы. Эти индексы указывают на заголовочный блока объекта или непосредственно к данным?

размер офигенный 3,2 Гига,

более того похоже дернули питание при записи, в результате в файле видны структуры к одинаковым таблицам дважды, но не по всем

Tool_1CD пробовал?

на заголовочный блок.

не берет ибо бит заголовок. Я немного нарисовал сам обработок и разбор файла на блоки провести могу. Вот только немного не въезжаю в логику адресации

зови Аву и молись

ша, уже почти все здесь. только не хватает до кворума

-  ну я вроде тоже так понял, т.е. 118 - это номер блока (с сигнатурой "1CDBOBV8" - из этого блока по соответсвующему смещению беру массив блоков с данными (опять же индексов) -  и теперь попадаю к блоку данных. Но вот взял на нормальном файле который читается Tool_1CD - и что-то по такому пути я не попадаю на нужное смещение (там и данные отображаются нужные и таблицы не битые) , но... что-то не так

То, что видны структуры к таблицам дважды - это нормально, такое бывает после реструктуризации. Реально, одна из структур находится в удаленных. Ну, где-то ты ошибся, может в блоке таблицы размещения файлов ты пытаешься взять как индекс блока с данными первое же число? Первое число - это количество индексов на данной странице таблицы размещения. Сами индексы начинаются со смещения 4.

А если упаковать, то сколько? 3 гига - это немного.

+ Или это уже упакованный размер?

- в принципе я не исключал такой ход. Нет это сама база, паковат не пробовол, за ненадобностью

А что значит бит заголовок? Какой блок испорчен? Блоки 0, 1 и 2 элементарно рисуются вручную, блоки 3 и 4 чуть сложнее.

по арифметике - мои алгоритмы (смотрю в реалии) Hex -редактором и Tool_1CD . К примеру вот такая строка: {"Files",5945,0,5950}. Значится в 5945-м блоке начало массива индексов с данными: смещение 5945*4096=24350720 (0х1378FFE). Там действительно блок 314344424F425638070500000100000001000000010000003C17 - то бишь вот он блок с данными (0х03С17) - иду туда (смещение 0х03С17000 - в байтах) - там не та хрень. Tool_1CD показыает смещение 0х173D08F - и там нужные данные

начала заголовка вообще нет 0,1 и 2 -я нарисую без проблем, да 3 и 4 сформирую, если разберусь с адресной арифметикой

Цитирую свою статью: В массиве blocks находятся индексы блоков, содержащих таблицу размещения данных объекта. Каждый блок, указанный в blocks, и являющийся частью таблицы размещения, имеет следующую структуру: unsigned int datablocks[1023]; } Т.е. в блоке 0х03С17 таблица размещения, а не сами данные.

помнишь я тебе говорил, что одинцы не стали себя утруждать и слизали структуру БД с фат? :)

+ Только, блок не 3C17, а 173C

Любой контейнер, хранящий в себе файлы и обеспечивающий произвольный доступ обязан иметь какую-то таблицу размещения. Тут дело не в слизывании.

- кстате давно хотел тебя спросить, а что будет если {"Files",118,119,96} заменить на аналог из configsave ? прокатит, или там внутрение идентификаторы разные?

Бррр... че-то не сразу вьезжаю. unsigned int datablocks[1023] - разве не массив блоков (то бишь размещения данных)?

Если в CONFIGSAVE загружена полная конфигурация (например, после операции "Загрузить конфигурацию из файла", то прокатит. Только надо будет удалить запись c файлом "deleted", если таковой окажется в CONFIGSAVE.

- а вот это посущественней, данные представлены в виде младший байт старший?

да, адрес 01 A0 - это смещение 0A 00 10 00

+ и с количеством нулей повнимательней, пони что добавляется 3 нуля а не 2 байта

-  а тут все верно? что-то я так не могу перевернуть

- что то у меня тут пробел, енто как?

адрес указывается в блоках, одни блок - это 10 00 (начало блока всегда заканчивается тремя нулями)

если адрес в hex редакторе 01 20 33 00 (4 байта), то смещение будет: (пишу текстовым сложением буковок) 00+33+20+01+000 = 03 32 00 10 00

Да, это уже массив блоков с данными. В твоем примере блок 5945 - заголовочный. У него структура Отсюда мы вытаскиваем номера блоков с таблицей размещения. У тебя это один блок 0x173c. Блок 0x173c имеет структуру struct { Отсюда уже вытаскиваешь индексы блоков с данными. Данные представлены обычным для виндовс способом - в младших байтах младшие. У тебя 3с младший байт, 17 - старший. И еще 2 байта нулевых еще более старшие. Он на 4096 умножает, так что дописывает 3 нуля - все правильно.

- это уже мерцает из-за разбивки по байтам. Все верно ( уж очень коррелирует с исходными данными)

- спасибо большое! теперь арифметика получается. Ну блин и напетляли. А еще вопрос по по поводу корневого блока: в массиве индексов находятся индексы блоков на блок с описанием таблицы? И 2-й - а последовательность указания таблиц в корневом блоке в таком случае имеет какое-нибудь значение?

:) и откуда я в прошлом сообщении взял ?...

>>>>корневого блока: в массиве индексов находятся индексы блоков на блок с >>>а последовательность указания таблиц в корневом блоке в таком случае имеет какое-нибудь значение нет

Блоки в массиве tableblocks указывают на заголовочные блоки файлов с описанием таблиц. И, как и сказал vde69, последовательность таблиц не важна.

- извините за настойчивость или непонимание, но тяжело дается переваривание терминов :) (особенно когда индексов на индексы и т.п.) - не в укор вам, понимаю что ноги то растут от предмета... Уточняю правильно ли я понял: то бишь в массиве индексов ссылки к описанию файла ({"_REFERENCE102",0, {"Fields", {"_IDRREF","B ....     и т.д. {"Files",5945,0,5950} То бишь к точке , с которой я начинал

спасибо! А еще один вопросик по структуре ужу самих таблиц. Наряду с таблицами базы  и т.п. вижу есть таблица FILES в нормальной базе и DBSCHEMA. В битой описания таких таблиц отсутствует. А что в них?

В FILES всякие вспомогательные файлы. Она не очень важна. А вот DBSCHEMA важна критически. В ней содержится структура базы данных. В двух местах, в DBSCHEMA и записи DBNames таблицы PARAMS содержится соответствие таблиц и полей объектам метаданных.

+ в DBSCHEMA и записи DBNames таблицы PARAMS разные данные, эти данные дополняют доуг друга, и они нужны одновременно. Без них база - бессмысленный набор таблиц.

Спасибо большое! А если их взять из копии -  может взлететь?

+ еще раз всем спасибо - пойду извлекать неизвлекаемое :)

Если это бэкап этой же базы с той же конфигурацией - взлетит. Если это просто база с такой же конфигурацией, то DBSCHEMA не подойдет. В разных базах разное соответствие. В одной базе Справочник Подразделения может быть в таблице _Reference57, а в другой это же справочник в таблице _Reference66. И DBSCHEMA будет уже другая.

Бэкам той-же базы, но полгода как, структура может чуть и изменилась , но мне главное вытянуть те данные, которые были в структуре полгода назад. Так что буду пробовать. Спасибо