История повреждена, некоторые данные утеряны.

cy6 писал(а):

Rapid D писал(а):

По идее должно пропуститься только одно событие!

Зависит от места повреждения.

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

В текущей версии контролируются следующие поля: what, event-type, длина extra-info (не более 16-ти байт, хотя мне кроме 12-ти байтового варианта еще не встречалось), длина body (не более 8кб, хотя реально в аське разрешены сообщения длиной не более 7кб, вроде бы). Думаю добавить еще контроль поля event-time на адекватный год.
Итак, если какое либо поле в записи истории (chunk) не подходит проверяемым критериям, запускается простой перебор следующих байт файлов (сквозное сканирование) на наличие поля what.

Пожалуй это можно назвать "женским" алгоритмом поиска ошибок

case getInt of
    HI_event:
      begin
...
      end;
    HI_hashed: hashed:=getString;
    HI_cryptMode:
      begin
...
      end;
    else
      begin
       if not quite then
         msgDlg(getTranslation('The history is corrupted, some data is lost'),mtError);
       result:=FALSE;
       exit;
      end;
    end;
  end;

Всю программу не вижу смысла выкладывать на альфа (по русски - сырой) стадии.

Разве chunk не начинается с поля what в "мужском" варианте?

Глянул мельком на вашу функцейку - жесть!
Если уж выкладываете только функцию, то думаю предполагается, что она не использует внешних переменных!
А то как-то странно видеть в ней всякие fErrorReason, fErrorPos, fHFile, fWhat, fSenderUIN, ...

THistFile = class (TObject)
  private
    fPath: string;
    fHFile: Cardinal;
    fErrorReason: Integer;
    fErrorPos: Integer;
    fWhat: Integer;
    fEventType: Byte;
    fSenderUIN: Cardinal;
    fEventTime: TDateTime;
    fExtraInfo: PByte;
    fExtraInfoLen: Integer;
    fBody: AnsiString;
  protected
    function getDecriptedBody: string;
  public
    constructor Create(Path: string);
    destructor Destroy; override;
    function FileOpen(UIN: Integer): Boolean;
    function FileCreate(UIN: Integer): Boolean;
    procedure FileClose;
    function ChunkRead: Boolean;
    function ChunkWrite(src: THistFile): Boolean;
    function ChunkFind: Boolean;
    property ErrorReason: Integer read fErrorReason;
    property What: Integer read fWhat;
    property EventType: Byte read fEventType;
    property SenderUIN: Cardinal read fSenderUIN;
    property EventTime: TDateTime read fEventTime;
    property Body: string read getDecriptedBody;
  end;

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

В целом алгоритм мне не очень нравится
Крайне неоптимально и хрупко.

Но думаю совместными усилиями сможем сделать хорошую лечилку

Но думаю совместными усилиями сможем сделать хорошую лечилку

Да, конечно.

Как они откроют файл истории "0Spamers"?
А ведь у некоторых людей он битый... (была ошибка в одном из билдов, и в этот файл писалось не то).

С нетерпением жду хотя бы бэтку.
Есть много-много ошибок по хистори, буду тестировать.

Я тоже жду результатов тестирования альфы, а конкретно, что остается в отремонтированном файле. В частности, непрерывная часть старой истории, и более новой.
Хотя, некоторые недостатки алгоритма уже известны, но все же...

Отремонтированных файлов просто нет. У меня "Альфа" удалила оригинал и оставила только с расширением bak. И всё.

Но думаю совместными усилиями сможем сделать хорошую лечилку

Да, конечно.

Тут я уже ожидал прочитать "жить вместе"

Алгоритм мне видица примерно таким:
1. Находим первые 2 точки в которых начинается последовательность #$FF#$FF#$FF#$FF.
2. Исследуем отрезок на правильность.
3. Находим 3-ю точку, в которой начинается последовательность #$FF#$FF#$FF#$FF
4. Исследуем второй отрезка на правильность записи.
5. Если оба правильные, то сдвигаемся на одну точку дальше (переход к шагу 3).
6. Если ошибок не встретилось, то END.

Я вот подумала, если повреждение будет где нибудь в поле длины (extra-info, body), с числом в большую сторону, то такая запись "проглотит" кусок нормальных записей. Этого можно избежать думаю только усложнением алгоритма от простого чтения, до сквозного первопроходного сканирования.

DC_ писал(а):

Отремонтированных файлов просто нет. У меня "Альфа" удалила оригинал и оставила только с расширением bak. И всё.

bak, это и есть переименованный оригинал.

Если Вам несложно будет его обратно переименовать (убрать расширение .bak), повторить процедуру, и скопировать сюда вывод программы (текстовая область "сообщения"), я была бы очень признательна. Там должны выводится ошибки.

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

Прячьте длинные логи под спойлер.

Да уж, вы разаритесь пожалуй

Непонятны мне всё же, зачем вы заостряете внимание на каких-то полях???
И под What вы понимаете метку начала записи?
Как то вы всё усложняете...

A CHUNK is so made:

int what
  case -1 (event)
    byte      event-type
    int       sender-uin
    datetime  event-time
    int       N
    N byte    extra-info   
    string    body (crypted)
  case -2 (hashed)
    string    hashed-password
  case -3 (crypt-mode) 
    int       following-data-length
    byte      crypt-mode (0 = simple, 1 = key method #1)

Алгоритм мне видица примерно таким:
1. Находим первые 2 точки в которых начинается последовательность #$FF#$FF#$FF#$FF.