= Сообщение: 2172 из 2457 =================================== RU.FTN.DEVELOP = От : Nil A 2:5015/46 02 Jun 23 18:15:58 Кому : Semen Panevin 02 Jun 23 18:15:58 Тема : TOCTOU FGHI : area://RU.FTN.DEVELOP?msgid=2:5015/46+647a09f3 На : area://RU.FTN.DEVELOP?msgid=2:5025/121+6476d636 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.FTN.DEVELOP?msgid=2:5030/723+647a18ec ============================================================================== * Originally in ru.golded * Crossposted in ru.ftn.develop Hello, Semen!
Wednesday May 31 2023 08:07, from Semen Panevin -> Nil A:
AK>>> проверить, что файло открыто достаточно легко: AK>>> [fido@fido local]$ lsof -u fido | grep msgbase AK>>> соответственно и пурджить можно проверяя, не открыт ли файл) AK>>> если уж совсем пытаться все предусмотреть.
NA>> Я начал тред именно с того, что вот такие вот решения и являются NA>> TOCTOU. Ты сначала проверишь, а потом пойдёшь пуржить или нет? NA>> ;-)
SP> Казалось бы, причём тут голдед? Пуржит-то по идее не он, а утилиты из SP> комплекта тоссера?
У меня есть идея, как можно починить именно голдед тут.
Пуржилка хватает лок на базу при своей работе, т.е. если в этот момент голдед бы держал лок, то пуржилка бы ждала. Но не комельфо всю дорогу держать лок на базу, поэтому голдед делает всё правильно, он открыл файлы баз, читает из них, а когда надо записать, он коротко берёт лок.
Сейчас проблема в юниксовом голдеде (линукс, фрибсд, макось, ..) в том, что он берёт лок на базу удачно, записывает сообщение, но потом оказывается, что это уже было на удалённом файле.
Моё предложение - голдед хватает лок, далее делает fstat() на этот открытый файл, проверяет поле st_nlink, и если там ноль, значит этот файл уже стёрли, значит надо переоткрыть файл. При этом тут TOCTOU не проиходит, потому что сначала успешно схвачен лок, а потом уже спокойно проверяется, не стёрт ли файл.
Best Regards, Nil --- GoldED+/LNX 1.1.5 * Origin: Linux 2.6.32-042stab145.3 (2:5015/46)
