https://bugs.exim.org/show_bug.cgi?id=3147
Bug ID: 3147
Summary: NFS file locking description incorrect
Product: Exim
Version: 4.98
Hardware: x86
OS: Linux
Status: NEW
Severity: bug
Priority: low
Component: Documentation
Assignee: unalloca...@exim.org
Reporter: eximus...@bebt.de
CC: exim-dev@lists.exim.org
Hello,
over in https://bugs.debian.org/960358 and
https://lists.exim.org/lurker/message/20200513.125602.7be7983c.en.html Vincent
Lefevre noted:
------------
spec. text says:
| use_lockfile Use: appendfile Type: boolean Default: see below
[...]
| In order to append to an NFS file safely from more than one host, it is
| necessary to take out a lock before opening the file, and the lock file
| achieves this. Otherwise, even with fcntl() locking, there is a risk of
| file corruption.
I don't see why. If used correctly, fcntl() locking should be
sufficient under NFS. And if fcntl() locking is broken, lock files
won't prevent corruption anyway: even if you have the lock, there
is no guarantee that the client will synchronize the changes with
the server before another process gets the lock and do changes
(this is the problem I had with shared zsh history, which often
got corrupted even though zsh used some form of locking... until
I patched it in 2008 to use fcntl() locking).
------------
Jeremy seemed to agree that this was dated, but the docs stayed unchanged.
Opening a report to track this.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
