Re: dotfile locking, NFS and lockd
First of all, thanks a lot for the clarification (and for all the work on
On 4 Mar 1998, Miquel van Smoorenburg wrote:
> In article <[🔎] Pine.LNX.3.95.980304140113.5868Afirstname.lastname@example.org>,
> Nelson Posse Lago <email@example.com> wrote:
> >that while all debian programs
> >(or all mail related programs?) agree in using dotfile locking, many of
> >them used the "wrong" function to implement that, since the commonly used
> >function is not atomic over NFS (meaning locking could fail over NFS on a
> >busy machine).
> Yes, using open("file", O_WRONLY|O_EXCL) is not atomic over NFS.
> There is a way around it however; you can install
> the libnfslock package. It's a preloaded library that intercepts the
> open() call. If you use O_EXCL, it does an NFS safe file create using
> a temp file and the link(2) system call.
> The libnfslock solution is good enough for now, and when all programs
> use the same locking protocol (which is dotlocking, or file based locking
> according to the Debian policy) you can remove libnfslock from your
> system. Note that it doesn't buy us much to move to fnctl() based locking
> with the kernel lockd, since as I said the most difficult part is to
> get all programs to just do locking in the same (safe) way, whether that
> is dotlocking or fnctl() locking.
Just to see if I got it straight:
By reading the material pointed on this list to me at
http://www.swb.de/personal/okir/lockd.html , It's my understanding that
the real usefulness of the lockd is that one can make "shared" locks
(everyone reads the file simultaneously, as long as everyone agrees
not to mess with the file while others are reading it) and posix locks
(to lock only a portion of a file, I guess that's important for
databases) work over the network, which is not possible now, but which is
not important for email. Correct?
E-mail the word "unsubscribe" to firstname.lastname@example.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to email@example.com .