= Сообщение: 1728 из 2735 =================================== RU.FTN.DEVELOP = От : Nil Alexandrov 2:5015/46 17 Mar 21 00:34:12 Кому : All 17 Mar 21 00:34:12 Тема : sqpack will reset BaseMsgNum to 1 FGHI : area://RU.FTN.DEVELOP?msgid=2:5015/46+6051249a = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.FTN.DEVELOP?msgid=2:5030/1997@fidonet+605196e0 Ответ: area://RU.FTN.DEVELOP?msgid=2:5020/545+60520513 ============================================================================== * Originally in ru.husky * Crossposted in ru.ftn.develop Hello, All!
Чем обычно пользователи Husky пуржат (JAM) базы, sqpack? А чем ещё можно пуржить под линуксом?
Под капотом sqpack, пользуясь smapi, открывает оригинальные файлы базы на чтение, временные на запись, копирует сообщения до лимита по времени и/или количество сообщений, и в конце замещает временные файлы на оригинальные файлы базы.
API smapi при создании базы JAM не позволяет указать BaseMsgNum (Lowest message number in index file) и всегда ставит там единицу. Я считаю, что поведение sqpack, когда упакованная база начинает нумерацию BaseMsgNum снова с 1цы не корректное.
Приведу пример, когда сброс BaseMsgNum в единицу ломает логигу других программ. jamnntpd/smapinntpd для отображения по NNTP количества сообщений всего/первое/последнее использует логику, что JAM .jdx файл - это записи по 8 байт на сообщение, соответственно можно сразу сказать сколько всего сообщений, а из заголовка в .jhr, сколько активных. Для NNTP клиентов важно, чтобы нумерация сообщений бала сквозной, тогда в следующий раз при соединении, клиент может понять, что появились новые сообщения. В случае с jamnntpd/smapinntpd всё работает до тех пор, пока базы не будут упакованы и тогда нумерация "съедет". Если бы в заголовке .jhr поле BaseMsgNum было минимальное значение сообщения, ещё из предыдущей базы, тогда, складывая BaseMsgNum со смещением по 8 байт в .jdx файле, можно было бы сохранить сквозную нумерацию.
