= Сообщение: 1735 из 2735 =================================== RU.FTN.DEVELOP = От : Alexey Vissarionov 2:5020/545 17 Mar 21 16:08:00 Кому : Nil Alexandrov 17 Mar 21 16:08:00 Тема : sqpack will reset BaseMsgNum to 1 FGHI : area://RU.FTN.DEVELOP?msgid=2:5020/545+60520513 На : area://RU.FTN.DEVELOP?msgid=2:5015/46+6051249a = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.FTN.DEVELOP?msgid=2:5015/46+605215be ============================================================================== Доброго времени суток, Nil! 17 Mar 2021 00:34:12, ты -> All:
NA> Чем обычно пользователи Husky пуржат (JAM) базы, sqpack?
А зачем вообще это делать? Почти 10-летний архив супола (трафик все представляют?) - меньше гигабайта. 14-летний архив отхеров :-) меньше полугигабайта. Остальное совсем мелочь.
NA> А чем ещё можно пуржить под линуксом?
Да хоть /bin/rm :-)
NA> Под капотом sqpack, пользуясь smapi, открывает оригинальные файлы NA> базы на чтение, временные на запись, копирует сообщения до лимита NA> по времени и/или количество сообщений, и в конце замещает временные NA> файлы на оригинальные файлы базы. NA> API smapi при создании базы JAM не позволяет указать BaseMsgNum NA> (Lowest message number in index file) и всегда ставит там единицу. NA> Я считаю, что поведение sqpack, когда упакованная база начинает NA> нумерацию BaseMsgNum снова с 1цы не корректное.
С чего бы это вдруг? В свежесозданной базе BMN по определению будет 1.
NA> Приведу пример, когда сброс BaseMsgNum в единицу ломает логигу NA> других программ. jamnntpd/smapinntpd для отображения по NNTP NA> количества сообщений всего/первое/последнее использует логику, NA> что JAM .jdx файл - это записи по 8 байт на сообщение, NA> соответственно можно сразу сказать сколько всего сообщений, а из NA> заголовка в .jhr, сколько активных.
Игого: авторы этих поделий не удосужились изучить документацию и что-то накосорылили. Программисты обычно называют это словом "баг" и стараются исправить.
NA> Для NNTP клиентов важно, чтобы нумерация сообщений бала сквозной,
Могу ошибаться, но вроде бы достаточно монотонности.
NA> тогда в следующий раз при соединении, клиент может понять, что NA> появились новые сообщения.
Эту нумерацию должен обеспечивать NNTP-сервер. К базе сообщений это непосредственного отношения не имеет (точнее, иметь не должно).
NA> В случае с jamnntpd/smapinntpd всё работает до тех пор, пока базы NA> не будут упакованы и тогда нумерация "съедет". Если бы в заголовке NA> .jhr поле BaseMsgNum было минимальное значение сообщения, ещё из NA> предыдущей базы, тогда, складывая BaseMsgNum со смещением по 8 байт NA> в .jdx файле, можно было бы сохранить сквозную нумерацию.
Вот есть софтина. Она создает базу сообщений (например, посредством их копирования откуда-то). С нуля. Вопрос: какого рожна она будет начинать нумерацию не с единицы?
-- Alexey V. Vissarionov aka Gremlin from Kremlin gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Существует два уровня защиты: high и нэхай --- /bin/vi * Origin: ::1 (2:5020/545)
