= Сообщение: 568 из 2735 ==================================== RU.FTN.DEVELOP =
От : Mithgol the Webmaster 2:50/88 22 Nov 14 22:27:12
Кому : Victor Smirnov 22 Nov 14 22:27:12
Тема : неправильный JAM или его кто портит
FGHI : area://RU.FTN.DEVELOP?msgid=2:50/88+5470e5c5
На : area://RU.FTN.DEVELOP?msgid=2:5020/830.97@fidonet.org+546c7ca5
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FTN.DEVELOP?msgid=2:5020/830.97@fidonet.org+5470f60a
==============================================================================
Так было 14:07 19 Nov 14 написано от Victor Smirnov к Mithgol the Webmaster:
VS>>> Никто не сталкивался с неверной длиной поля SubField, которые
VS>>> следуют за подзаголовками JAM в hdr файле?
VS>>> По сути sizeof(JAM)+JAM.SubLen должны указывать на следующий
VS>>> заголовок, но этого не происходит.
VS>>> Голдед отображает 98000 сообщений в области.
VS>>> Я добавил в програмку функционал сканирования файла на предмет
VS>>> поиска JAM\0 вперед от sizeof(JAM)+JAM.SubLen и насчитал 133000
VS>>> заголовков.
VS>>> Может кто из них пишет неправильный SubLen? или я неправильно
VS>>> читаю?
MtW>> По факту дела обстоят таким образом, что sizeof(JAM)+JAM.SubLen
MtW>> указывают на следующий заголовок только после упаковки базы командою
MtW>> `sqpack *` или другой аналогичной. Обычно же, если размер сообщения
MtW>> уменьшился (например, перед отправкою его отредактировали и что-то
MtW>> выбросили), то никто не заботится о перетаскивании последующих
MtW>> сообщений впритык к новому (укороченному) хвосту уменьшившегося
MtW>> сообщения.
VS> Причем тут редактирование сообщения? редактируется заголовок голдедом
VS> или в него вносятся изменения hpt он по сути нарушет стандарт JAM, вот
VS> кто из них? они не удаляют субтеги, а наоборот добавляют и не меняют
VS> поле, хотя и записывают заголовок. "поиска JAM\0 вперед" означает, что
VS> sizeof(JAM)+JAM.SubLen указывает не на новый 'JAM', а на subfild только
VS> что прочитанного заголовка - что вызывает резонный вопрос, кто портит
VS> базу.
Вот на этом месте я должен задать уточняющий вопрос, и задам.
По предыдущему твоему письму я понял дело так, что наблюдаемая проблема в том,
что отступ sizeof(JAM)+JAM.SubLen не укажет на следующий заголовок (но всё же
укажет, как я это понял тогда, на хвост последнего subfield).
Если же речь идёт о том, что само поле SubLen не верно, то есть что на самом
деле добавляются ещё какие-то субтеги, то это не то, о чём я рассуждал; не то,
что мне довелось наблюдать.
Иными словами, я наблюдал ситуацию, в которой sizeof(JAM)+JAM.SubLen указывает
не на новый последующий JAM (не на последующий заголовок). Однако ситуация была
вызвана тем, что следующий JAM-заголовок шёл в JHR-файле не сразу за предыдущим
JAM-заголовком. (И между ними был мусор, который и вправду может напоминать
какие-нибудь subfields, например.) Однако всё же sizeof(JAM)+JAM.SubLen надёжно
указывал на реальный хвост JAM-заголовка (фиксированной и переменной части его)
и на поле SubLen можно было полагаться.
У тебя так? Или у тебя не так?
Сразу скажу, что в межзаголовочном мусоре может быть буквально всё что угодно,
так что насчитать 133000 последовательностей 'JAM\0' в файле с 98000 реальными
заголовками сообщений ── это не удивительно. Мусор этот состоит, как правило,
из фрагментов ранее стёртых JAM-заголовков, так что части этого мусора могут
(и даже должны) напоминать либо начало JAM-заголовка (включая 'JAM\0'), либо
конец JAM-заголовка (то есть напоминать subfields).
Теперь настаёт ещё время поговорить о том, нарушается при этом стандарт JAM
или не нарушается. Чтобы поддержать (или чтобы устранить) уверенность в том,
что мы имеем в виду один и тот же стандарт JAM, я сразу скажу здесь, что стану
рассуждать на основании вот этого документа:
https://github.com/Mithgol/node-fidonet-jam/blob/ae36f04ceb57c7a12533c/JAM.txt
Если ты руководствуешься тем же самым документом, то прошу обратить внимание
на то обстоятельство, что он не требует того, чтобы JAM-заголовки в JHR-файле
шли непременно встык друг за другом. Совсем наоборот: этот документ содержит
такие инструкции по обращению с JAM-заголовками, которые предписывают в случае
роста размера JAM-заголовка (то есть такого роста, при котором новая версия
JAM-заголовка превосходит по размеру старую версию, хранящуюся в JHR-файле)
перетаскивать такой заголовок в конец файла. Прежняя версия заголовка в файле
при этом затирается лишь частично (флаг MSG_DELETED в атрибутах, поле TextLen
обнуляется) и в дальнейшем служит источником межзаголовочного мусора. Погляди,
вот эти инструкции:
https://github.com/Mithgol/node-fidonet-jam/blob/ae36f04ceb57/JAM.txt#L477-487
После этого можно рассмотреть два обстоятельства.
Во-первых, инструкции касаются только того случая, когда JAM-заголовок
разросся, и допускают при этом возникновение межзаголовочного мусора.
А о том случае, когда JAM-заголовок уменьшился в размере, ничего не сказано.
Первым приходящим на ум вариантом обращения с таким JAM-заголовком кажется
идея уменьшить SubfieldLen в соответствии с новой (уменьшенной) длиною.
Понятно, что при этом между этим заголовком и следующим опять же появится
межзаголовочный мусор (на сей раз напоминающий subfields по своей структуре),
но раз уж инструкции допускают межзаголовочный мусор в противоположном случае
(причём в объёме целого заголовка), то почему бы нам не допустить возникновение
такого мусора и в этом случае (в объёме всего-навсего нескольких subfields).
Во-вторых, раз уж межзаголовочный мусор появился, то в его сторону (насколько
хватит в нём места) может возрастать предшествующий ему заголовок (соответвенно
увеличивая SubfieldLen по мере нужды). При некоторой ловкости программиста
в сторону межзаголовочного мусора может возрастать и следующий заголовок (тут
одним изменением SubfieldLen не обойтись, а надобно будет также и в JDX-файле
указать новую, уменьшенную, позицию заголовка).
MtW>> Иными словами, прежде чтения заголовков из файла JHR неизбежным
MtW>> предшествующим шагом должно быть чтение файла JDX, в котором лежат
MtW>> смещения заголовков. Причём в файле JDX некоторые записи могут
MtW>> соответствовать удалённой фидопочте, так что надо отбрасывать те
MtW>> записи, в которых смещение или CRC равны FFFFFFFF. Вот тебе для
MtW>> примера мой код на языке JavaScript, занимающийся именно таким чтением
MtW>> файла JDX:
VS> и Это будет в корне неверно! т.к. этот файл не обязан содержать ссылки
VS> на удаленные письма, хотя и может.
Дык и что ж тут неверного? Если не будет он содержать ссылки на удалённые
сообщения ── хорошо же, пусть не содержит; тогда в записях просто нечего будет
отбрасывать, вот только и всего.
MtW>> После этого есть полный набор смещений и есть количество заголовков
MtW>> неудалённой фидопочты, оно-то и является числом сообщений в эхе.
VS> Но не базы, в базе будет больше писем, включая удаленные.
Игнорируй их.
MtW>> Располагая полным набором тех смещений, по которым в файле JHR
MtW>> располагаются заголовки фидопочты, становится возможно читать такой
MtW>> заголовок по его номеру;
VS> Эм. Конечно оно так.
VS> Но использовать буферизацию чтения - уже нельзя, ошибка будет.
VS> Мы не можем сделать:
VS> buf.head ::= READ <JAM> 76
VS> buf.sub ::= READ <JAM>,<buf.head.sublen>
VS> и далее работать с буфером в котором будут все подзаголовки
По моему опыту делать так можно, вот только не в цикле. Иными словами, чтение
76 байтов действительно получает фиксированную часть JAM-заголовка (4 байта
JAM-подписи, 2 байта Revision, 2 байта зарезервированы, 4 байта SubfieldLen,
4 байта TimesRead, 4 байта MSGIDcrc, 4 байта REPLYcrc, 4 байта ReplyTo,
4 байта Reply1st, 4 байта ReplyNext, 4 байта DateWritten, 4 байта DateReceived,
4 байта DateProcessed, 4 байта MessageNumber, 4 байта Attribute да ещё 4 байта
Attribute2, 4 байта Offset, 4 байта TxtLen, 4 байта PasswordCRC, 4 байта Cost),
а затем чтение SubfieldLen действительно позволяет прочесть переменную часть
(состоящую из подполей).
Просто после этого нельзя сразу вдругорядь ожидать появления JAM-заголовка там.
Во-первых, заголовок может идти в JHR-файле не сразу, а дальше.
Во-вторых, это может и не быть заголовок следующего сообщения, ведь инструкции
https://github.com/Mithgol/node-fidonet-jam/blob/ae36f04ceb57/JAM.txt#L477-487
позволяют переносить заголовок в конец JHR-файла без сохранения такого порядка
заголовков, который соответствовал бы порядку сообщений.
Вот почему, как я уж говорил в предыдущем письме на эту тему, JDX-файл всегда
бывает необходим. Только в нём можно узнать смещения JAM-заголовков в JHR-файле
и только в нём они идут по порядку.
VS> база испорчена и требует фикса. Судя по тому, что ты в курсе sqpack
VS> значит тоже встречался с этой проблемой, ты не проводил эксперименты - кто
VS> конкретно портит базу, потому как базу лучше пофиксить внеся в
VS> код-виновника необходимый патч?
GoldED делает это.
Однако трудновато будет тебе добиться пропатчивания.
Во-первых, как я о том поведал чуть выше, межзаголовочный мусор не противоречит
стандарту JAM, и в стандарте есть инструкции, следование которым обеспечивает
появление межзаголовочного мусора, обеспечивает следование заголовков не встык
(не непосредственно подряд) друг за другом, обеспечивает нарушение порядка их.
(Патч может быть отвергнут по принципу 'нельзя починить то, что не сломано'.)
Во-вторых, я не уверен в том, можно ли сейчас GoldED называть поддерживаемым
программным обеспечением. В октябре я задавал в эхоконференции Ru.GoldED такие
вопросы, на которые достаточно было просто ответить мне (а не патчить софт), но
никакого не получил ответа, так что мысленно плюнул и ушёл в другие эхи искать
ответа. Тогда уж тем более молчание будет и ответом на просьбы о пропатчивании.
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/
Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... Hадпись на зеркале: "Другие не лучше". (Александр Дашевский)
--- Последнее пpочитанное: "Год короля Джавана" Кэтрин Кёртц.
* Origin: А что нам йети // Да на это ответит? (2:50/88)
|
