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

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

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

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

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

Tool_1CD пробовал?

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

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

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

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

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

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

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

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

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

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

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

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

(16) Цитирую свою статью:

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

Т.е. в блоке 0х03С17 таблица размещения, а не сами данные.

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

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

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

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

прокатит, или там внутрение идентификаторы разные?

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

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

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

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

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

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

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

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

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

00+33+20+01+000 = 03 32 00 10 00

(23) Да, это уже массив блоков с данными. В твоем примере блок 5945 - заголовочный. У него структура

struct {
char[8] sig; // сигнатура “1CDBOBV8”
int length; // длина содержимого объекта
int version1;
int version2;
unsigned int version;
unsigned int[1018] blocks;
};

Отсюда мы вытаскиваем номера блоков с таблицей размещения. У тебя это один блок 0x173c.
Блок 0x173c имеет структуру

struct {
int numblocks;
unsigned int[1023] datablocks;
};

Отсюда уже вытаскиваешь индексы блоков с данными.

(25) Данные представлены обычным для виндовс способом - в младших байтах младшие. У тебя 3с младший байт, 17 - старший. И еще 2 байта нулевых еще более старшие.
(31) Он на 4096 умножает, так что дописывает 3 нуля - все правильно.

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

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

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

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

индексы - на файлы


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

нет

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

(36) - извините за настойчивость или непонимание, но тяжело дается переваривание терминов :) (особенно когда индексов на индексы и т.п.) - не в укор вам, понимаю что ноги то растут от предмета... Уточняю правильно ли я понял: то бишь в массиве индексов ссылки к описанию файла

({"_REFERENCE102",0,
{"Fields",
{"_IDRREF","B ....     и т.д. {"Files",5945,0,5950}

То бишь к точке , с которой я начинал

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

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

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

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

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

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

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