Вспомнить всё: 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

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]

Спасибо!