RnQ_Repair - утилита для работы с историей

Больше
11 года 11 мес. назад - 7 года 3 мес. назад #1 от cy6


Задача.
=======
Законченный инструмент для анализа и восстановления файлов истории мессенджеров семейства &RQ.

Возможности.
============
Поддержка истории шифрованной паролем (по оригинальной методике Rejetto), возможность получения всей
истории в текстовом виде, в любое время (поддерживаются кодировки Ansi, UTF-8, UTF-16 и UTF 16 big endian).
Проверка структуры файлов истории, возможность восстановления полей, составления карт содержимого файла (map)
в текстовом виде. Лог работы программы доступен в виде текстового файла, который также можно открыть
из самой программы двойным щелчком на окне сообщений.

Восстановление.
===============
Краткое описание особенностей восстановления полей истории:
- полям What, Event-Type в случае повреждения присваивается значение по умолчанию.
- полю UIN присваивается предыдущий UIN или UIN контакта (который соответствует и имени файла истории).
- полю Event-Time присваивается предыдущее значение или дата 01.01.2001 г.
- поля Extra-Info-Len, Body-Len пересчитываются заново если возможно.
- поле Extra-Info инициализируется по умолчанию.
Восстановление невозможно в случаях, если затерты одновременно поля Extra-Info-Len,
и Body-Len (все четыре байта).

В случаях, когда восстановление некоторых данных невозможно с точки зрения программы, эти данные не войдут
в файл отремонтированной истории. Неремонтированная версия (ОРИГИНАЛ) всегда сохраняется с расширением .BAK,
будьте внимательны, не удаляйте их, пока не уверены, что отремонтированная версия файла вас устраивает.
Всю информацию о записях, в том числе и о пропущенных данных (не подлежащих восстановлению) можно увидеть,
если задать формирование "карты файла" (map).

Также, необходимо помнить, что переименованные файлы истории (на другой UIN), будут считаться поврежденными,
поскольку программа сопоставляет содержимое полей UIN с UIN вашего аккаунта и UIN вашего собеседника,
для всех файлов истории, кроме 0spamers. Не делайте попытки ремонта таких файлов, они исправны.
В случае ремонта поля UIN будут заменены.

Тестирование.
=============
Программа тестировалась с мессенджерами &RQ (Rejetto) и R&Q (Rapid D.).
Проверка велась с файлами истории только по протоколу ICQ. Проверялась поддержка шифрования, формирования
текстовой истории в раскодированном (от других кодировок) читабельном виде.
Проверялось восстановление файлов истории, содержащим повреждения всех полей по порядку.

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

Указания на реальные ошибки в программе приветствуются. :)

Текущая версия. Устарела
===============
RnQ_Repair 1.0.1.212 RC-1 от 16.12.2009 15:57

MD5 8346d9fa490d11ea27c4c9f4fe6aee83 *RnQ_Repair.exe
SHA 70c2a8855fe8ae89c3b12cbcc2389160186db29a *RnQ_Repair.exe

Скачать можно со странички разработчика .

Пароль на исходники "c6lab.spb.ru".

P.S. Не стала упаковывать exe файл upx-ом, не вижу в этом смысла. Места на диске не сильно прибавится, а вот нагрузка лишняя (по распаковке сегментов) на процессор ляжет. Так что не пугайтесь размера файла, в нем только 5% моего кода, остальное - великие и могучие библиотеки CodeGear. :laugh:
Весь код полностью мой, в том числе и на ассемблере, ни откуда не спертый. :) Использованы только оригинальные функции шифрования истории от Rejetto и слегка упакованный мной (от неиспользуемых возможностей) модуль OverbyteIcsMD5. Также, для создания времени сборки использовался "BuiltTime.exe" из комплекта RnQ. Рисовать я тоже не умею, не ругайте за иконку, если можно. :silly:
Вложения:
Последнее редактирование: 7 года 3 мес. назад пользователем cy6.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 11 мес. назад - 11 года 11 мес. назад #2 от Rapid D
cy6 писал(а):

...
Также, необходимо помнить, что переименованные файлы истории (на другой UIN), будут считаться поврежденными,
поскольку программа сопоставляет содержимое полей UIN с UIN вашего аккаунта и UIN вашего собеседника,
для всех файлов истории, кроме 0spamers. Не делайте попытки ремонта таких файлов, они исправны.
В случае ремонта поля UIN будут заменены.
...

Мне кажется этот пункт можно либо сделать опциональным, либо как-то ещё убрать. (например сделать набор алиасов, что номер такой-то заменять на номер такой-то - это было бы идеально!)

А то представьте, если и я сменил себе номер, и собеседник - тогда в истории вообще все записи будут считаться поломанными, и заменит их на один и тот-же номер.
Последнее редактирование: 11 года 11 мес. назад пользователем Rapid D.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 11 мес. назад - 11 года 11 мес. назад #3 от cy6
Rapid D писал(а):

Мне кажется этот пункт можно либо сделать опциональным, либо как-то ещё убрать. (например сделать набор алиасов, что номер такой-то заменять на номер такой-то - это было бы идеально!)

Разумно, я то же об этом думала. :cheer:
Но решила оставить все дальнейшие улучшения до следующего релиза, который вберет в себя разумные предложения и исправления ошибок.

Текущий код был переписан полностью и увеличился в объеме где то в пять раз. пора его серьезно тестировать. :blush:

Rapid D писал(а):

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

Если собеседник сменил номер, то его история будет писаться в другой файл, насколько я понимаю? А если меняется номер пользователя, то разве не заводится другая папка и аккаунт?

При ручных манипуляциях с файлами, понятно, что возможно все. :side:

Вообщем, возможно сделаю опцию отключения проверки по UIN.
А вот как ее проверять с учетом переименованных и склеенных, как будет создаваться и пополняться такой список я не знаю. Потребностей подобных не было. Предлагайте. ;)

Можно было бы конечно залезть в DB (базу контактов), чтобы понять какие UIN допустимы, не будь она в зипе (да и еще в планами шифрования). Нет исходников упаковки распаковки DB5 (в 1100 упаковки еще не было), а лезть наугад не стоит, имхо.
Последнее редактирование: 11 года 11 мес. назад пользователем cy6.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 11 мес. назад #4 от DC_
Всё восстановил.
Отлично работает. Спасибо.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 11 мес. назад - 11 года 11 мес. назад #5 от cy6
DC_ писал(а):

Всё восстановил.
Отлично работает. Спасибо.

Я рада, что утилита оказалась полезной. Значит не напрасно делала. :)
Последнее редактирование: 11 года 11 мес. назад пользователем cy6.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад #6 от Пушкожук
Давно уже собираюсь написать, но всё никак не напишу... :) Итак:
У меня ошибок в истории не было, но на всякий случай решил проверить.
Результат - куча файлов истории с ошибками (много 109 и одна 102), хотя R&Q их прекрасно открывает :)
Стал смотреть...
Сначала разобрался с 102.
Подозрение вызвала строчка 200 в HistFile.pas:

//


event-type
PB := @fChunkFixBuff[4];
if ((PB^ >= HI_event_msg) and (PB^ <= HI_event_automsg)) then begin
fFields := fFields or SET_EVENT;
if (IsSave) then

В events.pas из исходников R&Q:
EK_automsg      = 14;
  EK_typingBeg    = 15;
  EK_typingFin    = 16;
//  EK_statuschangeExt = 17;
  EK_XstatusMsg   = 17;
  EK_Xstatusreq   = 18;
  EK_last         = 18;
EK_typingBeg и EK_typingFin действительно не могут попасть в файл истории, но EK_XstatusMsg и EK_Xstatusreq ведь могут :) Тогда 200-я строчка должна выглядеть примерно так:
if ((PB^ >= HI_event_msg) and (PB^ <= HI_event_automsg)) or (PB^ = HI_event_XstatusMsg) or (PB^ = HI_event_Xstatusreq) then begin
Теперь 109.
Очень хорошо, что я начал с 102, потому что 109 обнаруживается сложнее, а причина та же :) Если исправить 200-ю строчку, 109 тоже исчезает :) 102 появляется, если событие EK_XstatusMsg или EK_Xstatusreq первое в файле истории, а если оно есть, но не первое, то появляется 109.
Ещё ошибка: при создании текстовой истории выдаётся "Invalid pointer operation". С подобной ошибкой я уже сталкивался в программе R&Q History Reader. А возникает она из-за неправильно написанной процедуры Decritt - той, что в R&Q :) Просто по счастливому (или не очень) стечению обстоятельств в самой R&Q эта ошибка не возникает. Я даже боюсь предположить, сколько времени уже там находится эта ошибка... А заключается она в том, что процедура Decritt портит регистр esi, который должна была бы не менять. В R&Q процедура Decritt вызывается только из функции decritted, а там esi используется только до вызова Decritt. Короче, процедура Decritt должна выглядеть так:
procedure Decritt(var S: AnsiString; Key: Integer);
begin
  asm
    PUSH ESI
    MOV ECX, Key
    ..................
@OUT:
    POP ESI
  end;
end;
Ну, и ещё ошибка напоследок :) В одном файле была ошибка I/O 6/0. Подозреваю, что там очень большое сообщение (картинка). Увеличение буфера до 65535 байт помогло (но что, если картинка будет ещё больше? :)) Я тоже как-то писал класс для буферизованного чтения из файла, правда, не дописал... Но могу показать, если надо :) Там есть возможность чтения куска данных любого размера.
P.S. А можно dfm-файлы в исходниках тоже выкладывать? А то лень вытаскивать ресурсы из экзешника :silly:

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад - 11 года 10 мес. назад #7 от cy6
Пушкожук писал(а):

Давно уже собираюсь написать, но всё никак не напишу... :)

Наконец то, серьезное тестирование. :)

У меня ошибок в истории не было, но на всякий случай решил проверить.
Результат - куча файлов истории с ошибками (много 109 и одна 102), хотя R&Q их прекрасно открывает :)

Было бы гораздо хуже, если бы утилита читала, а RnQ нет. :laugh:
Задача программы - строгая проверка, для выявления ошибок. Сама RnQ, по состоянию версии 1100 контроля ошибок не производит, просто считывает, пока возможно.

EK_typingBeg и EK_typingFin действительно не могут попасть в файл истории, но EK_XstatusMsg и EK_Xstatusreq ведь могут :)

Это было добавлено в RnQ? В какой версии такие значения поля пишутся в хистори? В каком протоколе? (В моих файлах такие значения не встречаются, не на чем тестировать) У Rapid'a, кажется, времени так и не хватило выложить обещанные добавления к формату Rejetto.
Я руководствовалась форматом из "&RQ history file format.txt", в нем нет исправлений, связанных с добавлениями.

Ещё ошибка: при создании текстовой истории выдаётся "Invalid pointer operation". С подобной ошибкой я уже сталкивался в программе R&Q History Reader. А возникает она из-за неправильно написанной процедуры Decritt - той, что в R&Q :) Просто по счастливому (или не очень) стечению обстоятельств в самой R&Q эта ошибка не возникает. Я даже боюсь предположить, сколько времени уже там находится эта ошибка... А заключается она в том, что процедура Decritt портит регистр esi, который должна была бы не менять.

Эта ошибка досталась по наследству от самого Rejetto. :)
Опять же, из "&RQ history file format.txt". Не хотела переписывать данную функцию из уважения к автору, но видимо придется еще испортить регистр EDI. :laugh: Не нравится мне "MOV AL, [ESI]". :P
А регистры я обычно сохраняю все используемые, кроме флагов, как видно по остальным функциям, написанным мною.

Ну, и ещё ошибка напоследок :) В одном файле была ошибка I/O 6/0. Подозреваю, что там очень большое сообщение (картинка). Увеличение буфера до 65535 байт помогло (но что, если картинка будет ещё больше? :))

Я как то спрашивала, какой предел длины сообщения Body.
Не могли бы Вы уточнить, точно ли проблема связана с длиной поля Body. Также, интересен и источник такого огромного сообщения (протокол, метод, тип event).

Предел размера всегда есть, осталось только определится какой. А что если картинка будет больше 4гб? :woohoo: :laugh:

Я тоже как-то писал класс для буферизованного чтения из файла, правда, не дописал... Но могу показать, если надо :) Там есть возможность чтения куска данных любого размера.

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

В RnQ файл считывается целиком, данный метод мне тоже не нравится, уж слишком прожорливый и "детский".

Давайте определимся с максимальными размерами. Если этот вопрос неясен, если даже сделать перераспределение, то он все равно упрется в 32 битную арифметику, например.

Для почты, например, существует стандартное ограничение на размер письма в 10мб. Если даже не учитывать, что при кодировании в ASCII (Base64 и др), размер письма будет больше размера картинки, то многие картинки превосходят это значение.
Не хочется мучить виртуальную память виндоус и файл подкачки большими цифрами. Может быть большие по размеру Body просто вырезать?

P.S. А можно dfm-файлы в исходниках тоже выкладывать? А то лень вытаскивать ресурсы из экзешника :silly:

Как то забыла про них, тем более, что подготовленный человек знает где взять. :silly:
Но лень, это святое, ради этого можно исправиться. :laugh:
Последнее редактирование: 11 года 10 мес. назад пользователем cy6.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад #8 от AvRaTz
в общем на днях другу восстанавливал хистори..))сколько раз программа зависала-не счесть.. в итоге мною был выбран метод полной проверки и затем восстановления по одному файлу, восстановил почти все, один файл с хистори так и продолжает вешать программу и совершенно не хочет исправляться)

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад - 11 года 10 мес. назад #9 от cy6
AvRaTz писал(а):

один файл с хистори так и продолжает вешать программу и совершенно не хочет исправляться)

Если хотите выяснить причину, нужно как можно больше информации о самом файле (размер файла, карта файла). Лог программы в процессе зависания, если он не нулевой. Ну или сам файл, если не жалко, это лучше всего. :)
Последнее редактирование: 11 года 10 мес. назад пользователем cy6.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад #10 от Rapid D
cy6 писал(а):

Пушкожук писал(а):

EK_typingBeg и EK_typingFin действительно не могут попасть в файл истории, но EK_XstatusMsg и EK_Xstatusreq ведь могут :)

Это было добавлено в RnQ? В какой версии такие значения поля пишутся в хистори? В каком протоколе? (В моих файлах такие значения не встречаются, не на чем тестировать)

Вроде в 1100 это уже всё должно было быть.

В RnQ файл считывается целиком, данный метод мне тоже не нравится, уж слишком прожорливый и "детский".

А мне кажется для этой утилиты это самый правильный метод.
Вы засекали сколько занимает открытие истории в R&Q 1109 например, и сколько в той-же 1100?

Также, интересен и источник такого огромного сообщения (протокол, метод, тип event).

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

Думаю виновником этого сообщения является хороший плагин Pic-Is-Big: плагин для обмена изображениями

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад - 11 года 10 мес. назад #11 от Пушкожук
cy6 писал(а):

Это было добавлено в RnQ? В какой версии такие значения поля пишутся в хистори? В каком протоколе? (В моих файлах такие значения не встречаются, не на чем тестировать) У Rapid'a, кажется, времени так и не хватило выложить обещанные добавления к формату Rejetto.
Я руководствовалась форматом из "&RQ history file format.txt", в нем нет исправлений, связанных с добавлениями.

Протокол - ICQ (другие пока не тестировал). А когда было добавлено - даже не знаю... У меня давно уже такие настройки:

Я как то спрашивала, какой предел длины сообщения Body.
Не могли бы Вы уточнить, точно ли проблема связана с длиной поля Body. Также, интересен и источник такого огромного сообщения (протокол, метод, тип event).

Да, точно.

Источник - плагин R&Q Chat Pics или PicIsBig :) Они всю полученную или отправленную картинку сохраняют в историю как одно сообщение. Тип - HI_event_msg.

Сколько сама я этих классов писала, вспомнить сложно. При чтении куска размером больше чем размер буфера, размер буфера увеличивается.

Да вроде не увеличивается :) Вообще, там же два буфера: один - внутренний, который хранится внутри класса, другой - тот, в который записывает функция, т.е. выходной буфер. Второй-то всё равно придётся увеличивать, если читать chunk целиком, а первый можно не увеличивать :)

Может быть большие по размеру Body просто вырезать?

Не хочется портить правильную историю :) Может, их в txt не выводить? Всё равно это картинки. А скопировать из одного файла в другой (при восстановлении) можно и через буфер конечного размера.
Вложения:
Последнее редактирование: 11 года 10 мес. назад пользователем Пушкожук.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад - 11 года 10 мес. назад #12 от cy6
Rapid D писал(а):

В RnQ файл считывается целиком, данный метод мне тоже не нравится, уж слишком прожорливый и "детский".

А мне кажется для этой утилиты это самый правильный метод.
Вы засекали сколько занимает открытие истории в R&Q 1109 например, и сколько в той-же 1100?

С выключенным файлом подкачки, Windows тоже быстро работает. :)
А отключают его на свой страх и риск, риск получить сообщение, что память кончилась или посмертный BSoD.

Также и с файлами. Допустим, произошло невероятное, файл истории распух до 1гб, благодаря "умным" плагинам, которые "оригинально" сохраняют картинки. RnQ стоит на нетбуке с памятью 512 мб, файл подкачки выключен (для скорости, нетбуки шустростью не отличаются). Дальнейшие события думаю и так понятны... :S

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

Пушкожук писал(а):

Да, точно.
Источник - плагин R&Q Chat Pics или PicIsBig :) Они всю полученную или отправленную картинку сохраняют в историю как одно сообщение. Тип - HI_event_msg.

Мда. :blink:

А как BOS такой пакет пропускает? Ведь должны же у него быть какие то лимиты на размер пакета. Или можно послать 100 мб пакет, к примеру? :S

У самого плагина, лимиты какие нибудь есть?

- Изображение кодируется в Base64, бьётся на сообщения длиной 7500 символов и отсылается.
Чтобы переслать изображение весом 100 кб, нужно:
100 кб * 1024 * 1.33 / 7500 =~ 19 сообщений
Коэффициент 1.33 это из-за Base64 кодирования.
На другой стороне это изображение собирается и декодируется.

- Изображения до примерно 50кб показываются прямо в чате, как и при встроенном в крысу обмене. Ввиду ограничения 64кб на вывод в чат, изображения больше 50кб отображаются в отдельном окне (правый клик по иконке плагина открывает окно с последней большой полученной картинкой).


Вижу свою любимую цифру в 64кб. B) Предел? :unsure:

Тут еще один интересный момент. В алгоритме чтения файлов хистори в режиме "ремонта", я применяла сканирование признака начала Body, вернее поля BodyLen. Признаком этим являются два последовательных нулевых байта, в расчете на что, что поле BodyLen имеет значение 0-65535 и два старших байта не используются. Другие способы определения начала строки не представляю, учитывая, что в Юникоде нули в старшем байте слова (WCHAR) обычное дело.

Ввод-вывод перевела с 16 на 32 бита полностью, но при значениях выше обозначенных, описанный алгоритм придется отключать. Но какой то лимит на максимальный размер Body мы все равно должны выработать.

Decritt переписала. Специфичные значения поля EventType тоже добавила. Причем, программа определяет, с чем она запускается с &RQ или R&Q, и выбирает соответствующий диапазон допустимых значений для этого поля. Сделана опция отключения проверки значений UIN.
Для контроля зависания, добавила второй прогресс бар и инфу о текущем файле и позиции в файле.

Все это будет в новой версии, которая будет выставлена, после очередного "облизывания" кода.

Да вроде не увеличивается :) Вообще, там же два буфера: один - внутренний, который хранится внутри класса, другой - тот, в который записывает функция, т.е. выходной буфер. Второй-то всё равно придётся увеличивать, если читать chunk целиком, а первый можно не увеличивать :)

Логично, поняла. :)

Может быть большие по размеру Body просто вырезать?

Не хочется портить правильную историю :) Может, их в txt не выводить? Всё равно это картинки. А скопировать из одного файла в другой (при восстановлении) можно и через буфер конечного размера.

В txt однозначно выводить не стоит. Думаю взять лимит для длины текстовых сообщений в RnQ/&RQ, так как другого простого способа отличить нечитабельное сообщение с тем же значением HI_event_msg не представляю. :silly:

Но для буфера конечного размера тоже хотелось бы установить лимит.
Потому, жду совета по поводу конечного числа, так как мои лимиты оказались слишком плюшкинские. :blush:
Последнее редактирование: 11 года 10 мес. назад пользователем cy6.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад - 11 года 10 мес. назад #13 от AvRaTz
cy6 писал(а):

Ну или сам файл, если не жалко, это лучше всего. :)

пароль в ЛС

Вложение 340978397.zip не найдено


Файл наконец то прочитался, но абсолютно не восстановлен и крыса читает его, как битый, выдавая всем известное : история повреждена,некоторые данные утеряны
Вложения:
Последнее редактирование: 11 года 10 мес. назад пользователем AvRaTz.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад - 11 года 10 мес. назад #14 от cy6
AvRaTz, большое спасибо за чудесный экземпляр для тестирования и исправления недостатков утилиты.

Итак, это chunk (запись), которую не хотят грузить разные версии RnQ, вплоть до текущей. Но самое удивительное, что в RnQ 1100 она прекрасно загружается.
data: array[0..119] of byte = (
	$FF, $FF, $FF, $FF, $01, $52, $C0, $01, $00, $2E, $26, $0F, $E1, $FB, $9E, $E3, 
	$40, $14, $00, $00, $00, $FB, $9E, $E3, $40, $0C, $00, $00, $00, $01, $00, $00, 
	$00, $04, $00, $00, $00, $04, $03, $00, $00, $4B, $00, $00, $00, $FC, $D7, $A6, 
	$1C, $C5, $15, $12, $8B, $FC, $56, $AC, $18, $0B, $3F, $6A, $C4, $FC, $16, $AC, 
	$18, $0B, $3F, $4A, $9F, $DC, $AD, $D4, $18, $0A, $35, $CF, $81, $F9, $73, $78, 
	$38, $11, $35, $6F, $81, $59, $53, $42, $12, $EF, $CB, $6A, $C4, $FC, $F7, $AC, 
	$18, $4B, $35, $6E, $81, $38, $53, $03, $18, $89, $3F, $4A, $BF, $FC, $15, $86, 
	$26, $EF, $EB, $6A, $C7, $DC, $0B, $8D
);

Итого - файл не поврежден. Сообщения о повреждениях, при проверкой моей утилитой, можно было получить только если файл истории не лежал в родной папке и, соответственно, не проходил контроль UIN (либо UIN такой же как имя файла, либо как название папки, где лежит вся папка history), о чем я предупреждала в первом постинге. :) В новой версии уже есть возможность отключения этого строгого алгоритма.

Теперь о том, как исправить таки загрузку этого файлика в версиях после 1100.

Это, наверное, опять мой вопрос к Rapid D. :blush:

Данная запись, имеет настандартный блок ExtraInfo с длиной 20 байт, вместо 12-ти. Причем, стандартный 12-ти байтовый блок ExtraInfo получается как бы вложенный.
Содержимое блока с нестандартной (не 12 байт) длиной известно только разработчику. И поэтому, не контролируется, а контролируется лишь длина, которая в данном случае в порядке, как мы можем видеть.

З.Ы. Утилита не зависала, а просто работала долго (меняла каждый UIN на другой, так как проверка UINa не прошла из за перемещения из родного каталога). Отображение информации уже сделано (чтобы было видно, что программа работает, а не висит), ускорением скоростью работы буду заниматься. :blush:

Вот как на моей машине (C2D) выглядело, это "зависание":

12.01.2010 18:10:44 Запущен ремонт файлов
Файл истории: S:\R&Q\XXXXXXXXX\HISTORY\XXXXXXXXX
Размер: 1845712
ОК
12.01.2010 18:19:36 Завершено

Не зависание, а 10 минут работы...

Update
Нашла причину медленной работы. Сброс файловых буферов Windows на диск, без них то же самое длится 4 секунды. :)
Последнее редактирование: 11 года 10 мес. назад пользователем cy6.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад - 11 года 10 мес. назад #15 от cy6
cy6 писал(а):

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

Итак, это chunk (запись), которую не хотят грузить разные версии RnQ, вплоть до текущей. Но самое удивительное, что в RnQ 1100 она прекрасно загружается.

data: array[0..119] of byte = (
	$FF, $FF, $FF, $FF, $01, $52, $C0, $01, $00, $2E, $26, $0F, $E1, $FB, $9E, $E3, 
	$40, $14, $00, $00, $00, $FB, $9E, $E3, $40, $0C, $00, $00, $00, $01, $00, $00, 
	$00, $04, $00, $00, $00, $04, $03, $00, $00, $4B, $00, $00, $00, $FC, $D7, $A6, 
	$1C, $C5, $15, $12, $8B, $FC, $56, $AC, $18, $0B, $3F, $6A, $C4, $FC, $16, $AC, 
	$18, $0B, $3F, $4A, $9F, $DC, $AD, $D4, $18, $0A, $35, $CF, $81, $F9, $73, $78, 
	$38, $11, $35, $6F, $81, $59, $53, $42, $12, $EF, $CB, $6A, $C4, $FC, $F7, $AC, 
	$18, $4B, $35, $6E, $81, $38, $53, $03, $18, $89, $3F, $4A, $BF, $FC, $15, $86, 
	$26, $EF, $EB, $6A, $C7, $DC, $0B, $8D
);

Итого - файл не поврежден. Сообщения о повреждениях, при проверкой моей утилитой, можно было получить только если файл истории не лежал в родной папке и, соответственно, не проходил контроль UIN (либо UIN такой же как имя файла, либо как название папки, где лежит вся папка history), о чем я предупреждала в первом постинге. :) В новой версии уже есть возможность отключения этого строгого алгоритма.

Теперь о том, как исправить таки загрузку этого файлика в версиях после 1100.

Это, наверное, опять мой вопрос к Rapid D. :blush:

Данная запись, имеет настандартный блок ExtraInfo с длиной 20 байт, вместо 12-ти. Причем, стандартный 12-ти байтовый блок ExtraInfo получается как бы вложенный.
Содержимое блока с нестандартной (не 12 байт) длиной известно только разработчику. И поэтому, не контролируется, а контролируется лишь длина, которая в данном случае в порядке, как мы можем видеть.

З.Ы. Утилита не зависала, а просто работала долго (меняла каждый UIN на другой, так как проверка UINa не прошла из за перемещения из родного каталога). Отображение информации уже сделано (чтобы было видно, что программа работает, а не висит), ускорением скоростью работы буду заниматься. :blush:

Вот как на моей машине (C2D) выглядело, это "зависание":

12.01.2010 18:10:44 Запущен ремонт файлов
Файл истории: S:\R&Q\XXXXXXXXX\HISTORY\XXXXXXXXX
Размер: 1845712
ОК
12.01.2010 18:19:36 Завершено

Не зависание, а 10 минут работы...

Update
Нашла причину медленной работы. Сброс файловых буферов Windows на диск, без них то же самое длится 4 секунды. :)


======================================
AvRaTz, держите.
c6lab.spb.ru/RnQ_Repair.zip
Это вылечит Ваш файл. Не забудьте отключить галочку "Проверять поле UIN". :)

Это неофициальная новая версия. Временное решение, пока не решим чего делать с недокументированной длиной ExtraInfo. :laugh:
Последнее редактирование: 11 года 10 мес. назад пользователем cy6.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад #16 от AvRaTz
cy6 писал(а):

cy6 писал(а):
Не зависание, а 10 минут работы...

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

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

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад #17 от Rapid D
как мы видим,
ExtraInfo = $14, $00, $00, $00, $FB, $9E, $E3, $40, $0C, $00, $00, $00, $01, $00, $00, $00, $04, $00, $00, $00, $04, $03, $00, $00
В моём коде такого получиться не может.
Судя по записи "$FB, $9E, $E3, $40", этот текст каким-то образом взят из времени сообщения. И соответствует дате 01.07.2004.
Сомневаюсь что такая ошибка могла произойти в R&Q.
Может тогда запускали какую-то другую &RQ? :)
cy6 писал(а):

Данная запись, имеет настандартный блок ExtraInfo с длиной 20 байт, вместо 12-ти. Причем, стандартный 12-ти байтовый блок ExtraInfo получается как бы вложенный.
Содержимое блока с нестандартной (не 12 байт) длиной известно только разработчику. И поэтому, не контролируется, а контролируется лишь длина, которая в данном случае в порядке, как мы можем видеть.

Длина этого блока в порядке, а вот содержимое - не очень :)

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад #18 от AvRaTz
Опять!!! та же проблема, твоя программа снова пишет, что файл исправлен, но на деле при открытии крысой он снова читается как битый и хистори в него все равно не записывается..((
Прогнал снова, он снова нашел ошибку,снова исправил и снова не читается и так каждый раз))

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад - 11 года 10 мес. назад #19 от cy6
AvRaTz писал(а):

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

Потому что в каталоге лежит .BAK файл. Там ничего не должно быть, кроме оригинального файла. Дело в том, что BAK файл программа трогать не имеет права. Если она отработала, и .BAK файл там уже был, значит новый файл лежит там же с расширением .REP

Просто уберите у него расширение .REP и запускайте RnQ. :)
Я эту операцию проделала несколько раз, прежде чем выложить бинарник.

cy6 писал(а):
Не зависание, а 10 минут работы...

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

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

Файл абсолютно целый, кроме одной записи. Правда, в нем много дублирующихся записей. Я насчитала ошибку как раз на 23 дубликате.

Rapid D писал(а):

Длина этого блока в порядке, а вот содержимое - не очень :)

Так как же проверять блок ExtraInfo с длиной, отличной от 12-ти байт (документированной версии)?
Какая длина допустима и какое в нем содержимое?
Последнее редактирование: 11 года 10 мес. назад пользователем cy6.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
11 года 10 мес. назад #20 от ShineHead
Привет! Собственно это моя хистори тут рассматривается)
Сейчас убрал .бак и .реп и все норм. теперь в хистори дописывается все. Спасибо!
Но меня больше волнует причина такого глюка. Ну и я так понимаю то, что пропало из хистори уже безвозвратно... эх, знал бы прикуп)

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Модераторы: bassvazoozaDelphukdekRapid D
Время создания страницы: 0.556 секунд
Работает на Kunena форум