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

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

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

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

//

---

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

EK_automsg      = 14;
  EK_typingBeg    = 15;
  EK_typingFin    = 16;
//  EK_statuschangeExt = 17;
  EK_XstatusMsg   = 17;
  EK_Xstatusreq   = 18;
  EK_last         = 18;

if ((PB^ >= HI_event_msg) and (PB^ <= HI_event_automsg)) or (PB^ = HI_event_XstatusMsg) or (PB^ = HI_event_Xstatusreq) then begin

procedure Decritt(var S: AnsiString; Key: Integer);
begin
  asm
    PUSH ESI
    MOV ECX, Key
    ..................
@OUT:
    POP ESI
  end;
end;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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
);

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

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.

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

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

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

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

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

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

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

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

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

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

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

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