Вспомнить всё: lock file

[beldmit]

Освежил в памяти, как нынче заблокировать доступ к файлу на уровне C API.

Linux (и, видимо, прочие юниксы): flock работает всегда, lockf - для файла, открытого на запись. fcntl, наверное, тоже.

В Windows это не портируется, там надо звать Windows API, которое несовместимо в этом месте с OpenSSL BIO. И из виндового HANDLE получить дескриптор файла как-то можно, но это танцы с бубном.

На практике интересен ещё атомарный rename. В Unix-подобных системах, видимо, он действительно атомарный, попутно нашёлся эпический тред про то, как эту атомарность в MacOS 10+ чинили 3 года. В Windows есть ReplaceFile со товарищи, тоже со своими особенностями, и помеченная как deprecated функция для работы через транзакционный механизм NTFS.

Как это всё работает на NFS, не знает примерно никто.

Видимо, наиболее простое по программированию решение всех этих задач - внешнее по отношению к файловой системе, типа именованных мьютексов.

Comments

[elglin]

Я на нормальных языках не пишу, только скрипты; в Linux для баша использовал flock, на питоне эту задачу ни разу не решал - а вот на PowerShell проще использовать мутекс.
Честно говоря, если бы писал на голом C, то, наверное, не привязывался к файловой системе, а использовал семафор. Но я межпроцесску на сишке не писал со времен универа, так что мое мнение по рупь ведро.

NFS locking

[phd_ru]

Как это всё работает на NFS, все очень и очень хорошо знают. Плохо работает. Близко к никак.

Читать вопрос D10 в FAQ.

http://www.sqlite.org/faq.html#q5:

SQLite uses reader/writer locks to control access to the database. (Under Win95/98/ME which lacks support for reader/writer locks, a probabilistic simulation is used instead.) But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations.

Можно для вдохновения почитать исходники flufl.lock.

Re: NFS locking

[beldmit]

Спасибо!

[qkowlew]

Интересен тот факт, что при написании мной узлового тоссера для ФИДО я провёл пачку секспериментов в разных средах и убедился в том, что на произвольной FS нет надёжного безглючного решения, которое будет работать "везде и всегда".

Под ДОС, Win95 и последующих виндах - неразрушающий rename атомарен и может использоваться для создания файловых флагов вполне надёжно.

На системе с хардлинками - создание хардлинка в проверенных мной случаях - атомарная операция.

А ещё бывают построенные вируталки с доступом на запись к диску. :)

[beldmit]

Ну я надеялся, что за 10-15 лет с моего последнего взгляда в эту сторону всё изменилось. Ан нет. Хотя flock в MinGW могли бы и портировать.

[qkowlew]

rename ... В Unix-подобных системах, видимо, он действительно атомарный,

Но разрушающий.
Это делает его юзабельность для многих задач минимальной. :(

[yurikhan]

Разрушающий атомарный rename зато весьма юзабелен для реализации систем-версионников (в отличие от блокировочников).

[beldmit]

В каком смысле разрушающий?

[qkowlew]

$ touch 1
$ touch 2
$ mv 1 2
$ ls
2
$
при переименовании файл В который переименовывается - убивается, переименование успешно.

rename в unix C ведёт себя идентично.

в ДОС:

D:\> echo "">1
D:\> echo "">2
D:\> rename 1 2
Файл с таким именем уже существует
или не найден.
D:\> dir /b
1 2
D:\>
при переименовании наличие файла-мишени приводит к ошибке выполнения rename.