@MSGID: 2:5015/46 699944d1
@REPLY: 2:460/5858 6994cbf0
@CHRS: CP866 2
@TZUTC: 0300
@TID: hpt/lnx 1.9
Hello, Stas!

Tuesday February 17 2026 23:07, from Stas Mishchenkov -> Nil A:

 SM> А, вот, обнаружил я проблему, которую не знаю, как решать пока. Если в
 SM> OPUS Msg Base дед удаляет сообщение, то он не правит ластриды. Если
 SM> ластрид _другого_ пользователя указывает на удалённое сообщение с
 SM> большим номером, чем существующие, то так и останется. Если новые
 SM> сообщения будут тоже с меньшим номером, то они для другого
 SM> пользователя будут считаться прочитанными, а это не правильно и
 SM> чревато. На сколько я понимаю, починить это не трудно.

 Посмотрел. Обновление lastread происходит при _выходе_ из арии, не
важно для какой базы, логика одинаковая, и ластриды обновляются только для
_текущего_ пользователя.
 Такой подход работает для Squish и JAM в режиме "soft" удаления. В
OPUS/Msg сообщения удаляются всегда по-сути "hard", причём могут
переиспользоваться старые номера - тут и возникает описанная тобой проблема.

 Я посмотрел код Хаски утилиты sqpack, и при перепаковки баз, если
есть удалённые сообщения, то ластриды правятся для _всех_ пользователей. В
этом плане sqpack работает корректно.

 Чтобы починить голдед, нужно также править ластриды для всех
пользователей при удалении. Это немного другой интерфейс получится, а не то, что
сейчас close() вызывает у базы метод save_lastread() для текущего просто
пользователя.
Фикс возможен, но оне не в две строчки просто.

Best Regards, Nil
--- GoldED+/LNX 1.1.5-b20250409
 * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
SEEN-BY: 46/49 50/109 104/117 221/6 240/1120 301/1
341/66 451/31 452/28 166
SEEN-BY: 455/19 460/58 463/68 4500/1 5000/111
5015/42 46 255 5019/40 400
SEEN-BY: 5020/101 113 545 620 715 830 846 848
1042 2992 4441 12000 5022/128
SEEN-BY: 5029/32 5030/49 115 1081 1474 5049/1 3
5050/151 5053/51 58 5054/89
SEEN-BY: 5058/104 5060/900 5061/133 5068/45 5083/1
444 6078/80 6090/1
@PATH: 5015/46 5020/1042 4441