Ответ на сообщение Mithgol the Webmaster (2:50/88) к Victor Smirnov, написанное 18 Nov 14 в 18:57:
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> сообщения.
Причем тут редактирование сообщения? редактируется заголовок голдедом или в него вносятся изменения hpt он по сути нарушет стандарт JAM, вот кто из них? они не удаляют субтеги, а наоборот добавляют и не меняют поле, хотя и записывают заголовок. "поиска JAM\0 вперед" означает, что sizeof(JAM)+JAM.SubLen указывает не на новый 'JAM', а на subfild только что прочитанного заголовка - что вызывает резонный вопрос, кто портит базу.
MtW> Иными словами, прежде чтения заголовков из файла JHR неизбежным MtW> предшествующим шагом должно быть чтение файла JDX, в котором лежат MtW> смещения заголовков. Причём в файле JDX некоторые записи могут MtW> соответствовать удалённой фидопочте, так что надо отбрасывать те MtW> записи, в которых смещение или CRC равны FFFFFFFF. Вот тебе для MtW> примера мой код на языке JavaScript, занимающийся именно таким чтением MtW> файла JDX:
и Это будет в корне неверно! т.к. этот файл не обязан содержать ссылки на удаленные письма, хотя и может.
MtW> После этого есть полный набор смещений и есть количество заголовков MtW> неудалённой фидопочты, оно-то и является числом сообщений в эхе.
Но не базы, в базе будет больше писем, включая удаленные.
MtW> Располагая полным набором тех смещений, по которым в файле JHR MtW> располагаются заголовки фидопочты, становится возможно читать такой MtW> заголовок по его номеру;
Эм. Конечно оно так.
Но использовать буферизацию чтения - уже нельзя, ошибка будет. Мы не можем сделать:
и далее работать с буфером в котором будут все подзаголовки
база испорчена и требует фикса. Судя по тому, что ты в курсе sqpack значит тоже встречался с этой проблемой, ты не проводил эксперименты - кто конкретно портит базу, потому как базу лучше пофиксить внеся в код-виновника необходимый патч?
Со всеми регардами, Victor Smirnov (AKA MASM) --- Sys: NT_5.3/SP3+ GoldED+/W32-MINGW 1.1.5-b20110320 * Origin: Свет времени ведет нас сквозь мрак расстояний... (2:5020/830.97)
