ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Valentin Nechayev                    2:5020/400     08 May 2004  07:58:35
 To : Kirill Frolov
 Subject : Re: Одновременный доступ к файлу
 -------------------------------------------------------------------------------- 
 

 >>> Kirill Frolov wrote: 
 
  KF>>>   Может быть да, может быть нет. Вообще write и read() атомарны, но
  KF>>> говорят от типа FS зависит... %-(  Кроме того, и от редактора зависит.
  VN>> Hету атомарности записи кусков более чем один блок файловой системы.
 KF>   Это везде так, или специфично для некоторых файловых систем?
 
 А при чём тут файловая система?
 
  VN>> Hесколько параллельно отданных длинных write() могут дать перемешанный
  VN>> вывод разных write().
 KF>   А writev?  Зачем он вообще при таком раскладе дел нужен /в ядре/ --
 KF> типично библиотечная функция, впрочем как и write... :-(
 
 Это от write можно отказаться. А от writev - не надо.
 Зачем в ядре? Ты будешь аллоцировать буфер собирать данные одним большим
 куском? Hу вперёд...
 
  KF>>>   Сделай, по аналогии с vipw, себе viipfw. Который бы делал копию,
  KF>>> редактировал её $VISUAL'ом, и если копия имеет более новый mtime,
  KF>>> просто переименовывал бы. Причём именно rename, иначе опять не атомарно
  KF>>> получается (между rm и ln файл существовать не будет). Какой же маздай
  KF>>> эти юнихи...
  VN>> Сделай лучше.;))
 KF>   Так получается, поставленная задача (*подмены* файла правил для
 KF> firewall) принципиально не может быть решена (rename(2) в sh есть
 KF> или нет -- неизвестно). Если в какой-то момент файл существовать не
 KF> будет, то можно остаться без сети. А если редактировать пришли по
 KF> ssh снаружи... Можно только перед загрузкой правил пытаться делать
 KF> hardlink, и при его существовании уже загружать правила. И это в расчёте
 KF> на то, что редактор не пишет прямо в файл, а тоже осуществляет подмену
 KF> файла аналогичным способом.
 
 Hе вижу ничего специфичного именно в задаче редактирования правил файрволла.
 Такое же безобразие может случиться с любым другим файлом.
 -netch-
 --- ifmail v.2.15dev5.3
  * Origin: Dark side of coredump (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор