Monday January 29 2024 10:08, from Alexey Fayans -> Nil A:
NA>> Так-то можно заморочиться, в "дырки" писать.
AF> Формат Squish очень прост. Фреймы идут друг за другом. В индексе AF> хранится связь абсолютного номера соощения (UMSGID) с позицией фрейма AF> (Offset), и хэш поля To. Если Offset == 0, сообщение удалено. В JAM AF> примерно так же, просто -1 вместо 0. В обоих случаях (JAM и Squish) ты AF> можешь высчитать количество байт между концом последнего сообщения AF> перед удалённым и началом первого сообщения после, и если места AF> хватит, пихнуть туда фрейм. Правда в случае с JAM нужно будет такой же AF> фокус проделать ещё и с файлом заголовков. Довольно трудозатратно и AF> напрочь лишено смысла, поэтому так никто не делает, насколько мне AF> известно.
Меня всегда завораживало следить за defrag утилитой, изначально из Нортон Утилит которая. Как ей тяжело приходится, перемещать маленькими кусочками туда-сюда.
А вот пуржилки всегда были такими, что новый файл базы создают и туда сообщения из старой базы накидывают. Или были пуржилки, которые как defrag.exe кусочки внутри перемещают?
NA>> Хотя, есть проблема с Jam, там можно удалять по-разному, и даже NA>> голдед имеет настройку как именно удалять.
AF> В JAM есть аттрибут MSG_DELETED (0x80000000L), голдед может считать AF> сообщения с этим аттрибутом удалёнными (как и задумано), а может их AF> отображать. Никаких других настроек на эту тему в голдеде нет, и AF> проблем никаких это не вызывает.
Проблема, что не все одинаково понимают, что такое удалённое сообщение. Многим обязательно надо, чтобы в индексе было -1, и не лезут они вычитывать MSG_DELETED, ибо это долго.
Best Regards, Nil --- GoldED+/LNX 1.1.5 * Origin: Linux 2.6.32-042stab145.3 (2:5015/46)
