NA> Пуржилка хватает лок на базу при своей работе, т.е. если в этот момент NA> голдед бы держал лок, то пуржилка бы ждала. Но не комельфо всю дорогу NA> держать лок на базу, поэтому голдед делает всё правильно, он открыл NA> файлы баз, читает из них, а когда надо записать, он коротко берёт лок.
Редактор и тоссер не должны быть взаимозависимы - представь вместо голдеда штатный (для husky) msged.
NA> Сейчас проблема в юниксовом голдеде (линукс, фрибсд, макось, ..) в NA> том, что он берёт лок на базу удачно, записывает сообщение, но потом NA> оказывается, что это уже было на удалённом файле.
K.I.S.S. База сообщений - это территория редактора. А возможно, еще и BBS. В любом случае, ЧМИ (для чтения хомосапиенсами). Тоссер должен быть адаптирован (и он адаптирован, флагами), к наименее конфликтной работе. Пуржилка относится к инструментам обслуживания. А обслуживаение - это зона повышенного внимания сисопа/админа/босса качалки. Так что сисопу и городить проверку на занятость базы оконечным сапиенсом.
NA> Моё предложение - голдед хватает лок, далее делает fstat() на этот NA> открытый файл, проверяет поле st_nlink, и если там ноль, значит этот NA> файл уже стёрли, значит надо переоткрыть файл. При этом тут TOCTOU не NA> проиходит, потому что сначала успешно схвачен лок, а потом уже NA> спокойно проверяется, не стёрт ли файл.
Голдеду достаточно в данном случае поставить лок - никто их husky базы не тронет. Но тут другая проблема - пока у тебя открыт голдед, тоссер (и пуржилка, и весь комплект) будет отваливаться "до лучших времен". А сейчас ты можешь заресканить измененную тоссером базу. Пр
Alexey Khromov --- GoldED+/LNX 1.1.5-b20230304 * Origin: - Вы в опасности! Вы окружены роботами! - (2:5030/723)
