Привет всем читающим эти строчки. Получилась так, что мне, в общем то далекому от именно 1с человеку, приходится восстанавливать сломанную после сбоя питания базу 8.2. .

Первый успех уже есть, после некоторых манипуляций Tool_1CD базу увидел:)
Перелопатив кучу форумов, описание формата 1CD, вооружившись винхексом и дельфей, а также годичным бекапом несчастной базы
и кофе я понял что в базе убит корневой раздел.
Т.е. в таблице смещений сбита адресация, значение может быть меньше предыдущего, а то и вообще может вести за пределы базы.

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

лучше

обратитесь к специалистам в этом вопросе:
awa15 (автор тул сиди)
и
vde69 (http://www.sql.ru/forum/actualthread.aspx?tid=971669)

бэкап когда же научаться делать ежедневный ?

http://infostart.ru/public/158034/
http://forum.infostart.ru/forum26/topic73004/message780847/#message780847

(0) если база не очень большая (1-2 гига) грузи ее в конфу востановления и смотри корневой обьект как таблицу, там показываются реальные ссылки и все что записано, и серым диапазоном выделено то что находится за индексом количества записей.

В 90% случаях ничего перегенерить не нужно, обычно все траблы - это 1-2 ссылкы или размер таблицы кривой.

(4)+ кстати если хочется "по быстрому" - то можно все и не грузить, а сначало создать блоки (это минут 10) и потом на блоке с номером 2 меню "загрузить таблицу", тогда сразу увидешь только один корневой

(5) а вы где этому научились? я тоже хочу быть гуру восстановления

(6)
И Андрей закричал: Я покину причал,
 Если ты мне откроешь секрет.
И Спаситель ответил: Спокойно, Андрей,
 Никакого секрета здесь нет.

Видишь, там на горе   возвышается крест.
 Под ним десяток солдат,   повиси-ка на нём,
 А когда надоест,   возвращайся назад
 Гулять по воде, гулять по воде,
   гулять по воде со мной.

----------------------
просто нужно потратить N времени что-бы вьехать в проблемму...

спасибо за ответы, пошел пробовать...

да, вопрос гуру. что за блок находится по адресу 0x2000, у меня там в ломанной базе даже заголовка нет, одни нули...

(9) там обычно меньее 50 байт заполнено

ну да, заголовок и 8байт, но без этого tool_1cd не открывала файл.

tool_1cd без коневого вроде вообще не открывает, по этому если она открывает - то как минимум часть корневого цела и говорить что в блоке  0x2000 одни нули - это обманывать себя.

Здесь форум где нужно говорить правду, даже если там трипер :)

я говорю правду всегда, даже если там не только триппер)
изначально - в базе вместо заголовка в первом блоке были  нули и по адресу 0x2000 - пусто.
после вбития заголовка и переноса 16 байт из старой бекапленой базы в 0x2 файлик открылся в tool_1cd с кучей ошибок (отсутсвует dbschema, много - блок не является обьектом, ошибка парсинга и разбора раз так 60 итд)

в общем после этого я прочитал что лежит в 0x4000 в старом бекапе и в ломанной базе.
если перевести смещения из блока 0x4 в интегер получается так:
5,764,836...,2118,2128, 79635,74184,1475 ну итд)
насколько я понял в исправном корневом все смещения должны идти друг за другом. отсюда мой вывод - надо пробовать копать корневой...

вот и вся моя грустная история, грустная потому что базу поднимать придется мне, хотя про формат 1cd я узнал не далее как 2 дня назад.

(13) ну лечить по телефону вряд-ли выйдет....

база нужна, так это все слова...

короче пиши на почту :) или мне или awa15 и сразу про вознаграждение не забудь :))))

После нгово колчичества часов ковыряния очень хочется попытаться разобраться самому, если таки не выйдет то прошу вашего разрешения на самом деле написать на почту...

про вознаграждение разумеется не забуду:)

(13) Совершенно необязательно эти блоки должны идти в возрастающем порядке. Да, обычно они идут в возрастающем порядке, но не всегда.
Раз уж ты восстановил блок 0х2000, то попробуй сделать так:
Посмтори, какое число 4х байтовое число записано по адресу 0х4020. Умножь это число на 4 и прибавь 0х24. Плучившийся результат запиши по адресу 0х2008.
Например: Смотрим 0х4020, видим там Е3 00 00 00, значит наше число 0хЕ3. Умножаем на 4, получаем 0х38С, прибавляем 0х24, получаем 0х3В0. По адресу 0х2008 пишем байты В0 03 00 00.

однако! исчезли все ошибки кроме 2х - ошибка получения обьекта из блока и индекс первого блока за пределами файлов индексов.

а что же лежало в чудном блоке x2000?

(18) я даже знаю какие остались

1. общая длина файла не соответствует заголовку
...


теперь попробуй зайти chdbfl (в каталоге 1с) и потом в конфигуратор и там запустить сжатие базы :)

разумеется на копии

Блок 0х2000 - заголовочный блок корневого файла, блок 0x4000 - содержимое этого файла. Так как ты скопировал блок 0х2000 из другой базы, то у тебя в нем была неправильная длина корневого файла (байты в 0х2008). Для корневого файла существует простой способ вычислить правильную длину, которую я и написал.

(21) к (19), сорри

(19) там есть две волшебные цыфры
Длинна (ее можно и посчитать), и количество блоков "Dir" (обычно от 1 до 3х).

(17) кстати если база  была 8.0 то вместо "прибавь 0х24" нужно чуток поменьше :)

Не, остались:
"ошибка получения обьекта из блока. Блок не является обьектом",
по адресу блока - нули,
и
"ошибка чтения индексов. Индекс первого свободного блока за пределами файла индексов"
длина файла индексов x7000, индекс свободной страницы - 0x42444331

chdbfl файл не открывает...

блин, а я уже начал писать парсер на дельфе, а ларчик то вот как открывался!

(23) Скорее всего ты имеешь ввиду блок с таблицей размещения файла. Для корневого блока это обычно 0х3000. В 0x2000 только длина и ссылка на таблицу размещения.
(24) ТС написал 8.2, так что 0х24))
(25) Тогда еще попробуй уменьшить значение по 0x4020 на 1, а значение 0х2008 на 4.

общая длина файла не соответствует заголовку  - нету такой)
база 8.2.14

(25) на ошибку "ошибка чтения индекса" наплевать. Надо избавиться от "ошибка получения объекта из блока". Тогда chdbfl базу обработает.

ошибка получения обьекта из блока - адрес 0x851 - по этому адресу пусто, даже заголовка нет

(30) блок 0х851 - это адрес 0х851000

>>блок 0х851 - это адрес 0х851000
да я это и имел в виду, забыл нули дописать
>>Тогда еще попробуй уменьшить значение по 0x4020 на 1, а >>значение 0х2008 на 4.
ошибка осталась, потерялась dbschema

(32) Это хуже. Какие значения у тебя в блоке 0х3000? Там 2 или 3 числа должны быть

И скажи значение 0х2008

записал по адресу 0x851000 заголовок "1CDBOBV8" - ошибка в tool_1cd пропала,
chdbfl все равно ругается "Повреждена таблица размещения внутреннего файла <Описание базы данных>"

(35) Не, это не поможет. Надо найти в корневом файле блок 0х851, и удалить его

0x2008 - 0c3e
0x3000 - 01 00 00 00  и 04 00 00 00

Отлично! Найди байты 51 08 00 00, начиная с адреса 0х4024, и напиши, по какому адресу ты их нашел

0хС3Е - это после уменьшения на 4, про которое я говорил в (27) или после?

*или до

Кстати, 0xC3E - явно неправильное число, оно должно на 4 делиться

>>0хС3Е  - после
(38) первое вхождение внутри текста по af200,
среди нулей - 003d1200

c3e\4=30f вроде...

(42) А какое было до? Кажется, ты что-то неправильно посчитал. Если было раньше С40, то С40 - 4 = С3С.
(43) 30F * 4 = C3C
А вот то, что ты не нашел байты 51 08 00 00, это я не понимаю. Они должны были быть в промежутке 0х4024 - 0х4С40

+(44) Если их там нет, то и chdbfl не должен падать. А раз он падает, эти байты должны быть в корневом файле!

А скажи, какое значение изначально было по адресу 0x4020?
Может ты неправильно посчитал 0x2008 и поэтому и chdbfl падает?

так, да, наверно туплю.
1. 51 08 нет, точно есть 50 08

по 0x4020 f200

(48) т.е. по адресу 0х4020 изначально были байты F2 00 00 00?
Если так, то по адресу 0x2008 должно быть число 0х3EC (байты EC 03 00 00)

(49) да,туплю, блин((

(49)(50) быстрее файл передать....

(51) Ну, это в качестве эксперимента)) Вдруг получится))

...! получилось! ошибка блока осталась, но chdbfl поколдовал и все запустилось!

awa15! вы спасли меня от семейной расправы! с меня причитается, завтра с вами свяжусь!

(52)учитывая что таблица схема при каждом обновлении может поменять свое место на ближе к концу, то игры с копированием корневого из полугодичного бекапа - выглядят сильно сомнительно....

буду сейчас анализировать все вышенаписанное, хотя надеюсь не пригодится никогда)

(53) Ура))
В конфигураторе после chdbfl запустилось? На копии попробуй в ТиИ сделать сначала реиндексацию, затем реструктуризацию. Если пройдет - все в пордке.
(55) Сам корневой был в порядке (0х4000), битым был заголовочный блок корневого (0х2000).

на реиндексации правда вылетает...

но это уже мелочи. еще раз всем спасибо!

(58) Попробуй перед реиндексацией сделать сжатие таблиц.

awa15, отписался на почту.