rename()

[Valentin Nechayev]

Hi,
SEL>> Hа мой непросвещённый взгляд, любое количество таких выражений
SEL>> выполняемых параллельно, гарантировано выполнят успешно одно и
SEL>> только одно переименование, и только в случае отсутствия dst.
SEL>> Или я не прав?

PG> Да, race condition тут действительно исключён, а неатомарность
PG> выражается лишь в том, что в какой-то момент времени присутствует и
PG> старый, и новый файл одновременно. Соответственно, если unlink() по
PG> какой-то причине завершился с ошибкой, у нас так оба файла (точнее,
PG> оба имени файла) и останутся, а такое состояние может быть
PG> нежелательным - например, порождать дубликаты сообщений.

Потому в правилах работы с maildir есть явный контроль (по st_nlink) и откат
таких ситуаций.
Фактически DJB построил лёгкие транзакции вокруг атомарных действий FS,
таких, как link и unlink.


-netch-

[Serguei E. Leontiev]

Привет Валентин,

От 10 июня 2015 г., 11:50:52 в fido7.ru.unix.prog ты писал:
SEL>>> Hа мой непросвещённый взгляд, любое количество таких
SEL>>> выражений выполняемых параллельно, гарантировано
SEL>>> выполнят успешно одно и только одно переименование, и
SEL>>> только в случае отсутствия dst. Или я не прав?
PG>> Да, race condition тут действительно исключён, а
PG>> неатомарность выражается лишь в том, что в какой-то момент
PG>> времени присутствует и старый, и новый файл одновременно.
PG>> Соответственно, если unlink() по какой-то причине
PG>> завершился с ошибкой, у нас так оба файла (точнее, оба
PG>> имени файла) и останутся, а такое состояние может быть
PG>> нежелательным - например, порождать дубликаты сообщений.
VN> Потому в правилах работы с maildir есть явный контроль (по
VN> st_nlink) и откат таких ситуаций.
VN> Фактически DJB построил лёгкие транзакции вокруг атомарных
VN> действий FS, таких, как link и unlink.

И так будет до тех пор, пока не определят нормальные транзакции на
файловой системе :)

--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru