= Сообщение: 569 из 2735 ==================================== RU.FTN.DEVELOP = От : Victor Smirnov 2:5020/830.97 22 Nov 14 23:24:36 Кому : Mithgol the Webmaster 22 Nov 14 23:24:36 Тема : Re: неправильный JAM или его кто портит FGHI : area://RU.FTN.DEVELOP?msgid=2:5020/830.97@fidonet.org+5470f60a На : area://RU.FTN.DEVELOP?msgid=2:50/88+5470e5c5 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Приветствую тебя, Mithgol!
Ответ на сообщение Mithgol the Webmaster (2:50/88) к Victor Smirnov, написанное 22 Nov 14 в 22:27:
MtW> @GRAVATAR: f28c5c365d037593c6a45e94d678e74a MtW> Так было 14:07 19 Nov 14 написано от Victor Smirnov к Mithgol the MtW> 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 он по сути нарушет VS>> стандарт JAM, вот кто из них? они не удаляют субтеги, а наоборот VS>> добавляют и не меняют поле, хотя и записывают заголовок. "поиска VS>> JAM\0 вперед" означает, что sizeof(JAM)+JAM.SubLen указывает не VS>> на новый 'JAM', а на subfild только что прочитанного заголовка - VS>> что вызывает резонный вопрос, кто портит базу.
MtW> Вот на этом месте я должен задать уточняющий вопрос, и задам.
MtW> По предыдущему твоему письму я понял дело так, что наблюдаемая MtW> проблема в том, что отступ sizeof(JAM)+JAM.SubLen не укажет на MtW> следующий заголовок (но всё же укажет, как я это понял тогда, на хвост MtW> последнего subfield).
MtW> Если же речь идёт о том, что само поле SubLen не верно, то есть что на MtW> самом деле добавляются ещё какие-то субтеги, то это не то, о чём я MtW> рассуждал; не то, что мне довелось наблюдать.
MtW> Иными словами, я наблюдал ситуацию, в которой sizeof(JAM)+JAM.SubLen MtW> указывает не на новый последующий JAM (не на последующий заголовок). MtW> Однако ситуация была вызвана тем, что следующий JAM-заголовок шёл в MtW> JHR-файле не сразу за предыдущим JAM-заголовком. (И между ними был MtW> мусор, который и вправду может напоминать какие-нибудь subfields, MtW> например.) Однако всё же sizeof(JAM)+JAM.SubLen надёжно указывал на MtW> реальный хвост JAM-заголовка (фиксированной и переменной части его) и MtW> на поле SubLen можно было полагаться.
MtW> У тебя так? Или у тебя не так?
Вот пример не удаленного сообщения, его можно наблюдать в голдеде. Да, похоже на мусор за заголовком. Что-т я об этом не подумал.
вобщем-то, вопрос снят... Про мусор я как-то забыл.
Со всеми регардами, Victor Smirnov (AKA MASM) --- Sys: NT_5.3/SP3+ GoldED+/W32-MINGW 1.1.5-b20110320 * Origin: Свет времени ведет нас сквозь мрак расстояний... (2:5020/830.97)
