Homer Wilson Smith <homer(_at_)lightlink(_dot_)com> writes:
Is there a white paper that describes in detail how
file locking is done with procmail?
Not that I know of. The source is probably your only bet for seeing
what's going on. The function lockit() in src/locking.c, together with
xcreat() and most the functions in src/exopen.c, perform 'dotlocking',
the exclusive creation of the "whatever.lock" file.
Kernel locking is performed by the fdlock() and fdunlock() functions in
src/locking.c These functions are not for the weak of heart. The comment
before fdlock() reads:
/* if you've ever wondered what conditional compilation was good for */
/* watch closely :-) */
as it has to deal with all seven possible combinations of usable kernel
locking functions (the eighth combo, "nothing works", is a simple #ifndef
around the entire lump)
In particular over NFS.
The main difference when NFS is involved is that system calls may end
up 'lying' about their results. The O_EXCL flag to open() doesn't
reliably fail over NFS**, so you have to create a temp file and link()
it into place. Then link() can succeed, but return failure. Then you
have to deal with stale locks. The list goes on...
Philip Guenther
Procmail Maintainer
** NFSv3 was supposed to fix this particular problem, but implementation
bugs mean you still can't really trust it. A co-worker of mine on a
previous project managed to coax an up to date Solaris box (yes, from
the people who co-wrote the NFSv3 standard) into failing to implement the
'checked open' correctly, with the NFS trace to prove it. Oh well...
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail