Re: problem with folder locking: procmail and pine
On 03 Mar, Manoj Srivastava wrote:
> Hi,
> >>"Malc" == Malc Arnold <malc@thing.demon.co.uk> writes:
>
> Malc> On 2 Mar, John Goerzen wrote:
> >> On Mar 2, Santiago Vila Doncel wrote:
> >>
> >> What's wrong with using dot-locking in conjunction with
> >> fcntl/flock?
>
> Malc> It blows up horribly if /var/spool/mail (or the local
> Malc> equivalent) is mounted via NFS. Dot-locking is the *only*
> Malc> reliable locking mechanism in that case; and since a Debian
> Malc> package can't know in advance what its run-time environment
> Malc> should be, then it shouldn't use any locking mechanism except
> Malc> .lock files.
>
> Could you please elaborate on ``blows up horribly''? I was
> under the impression that fcntl/flock would fail if the file were NFS
> mounted, in which case the dot locking mechanism ensured exclusive
> access, and for local files either method by itself would work.
>
> In other words, using both methods would not be harmful, which
> is contrary to what ``blows up horribly'' conveys to me.
I've been reliably informed that there are some utterly broken NFS
implementations (from Sun of all people, and quite possibly others)
which can handle lockf across an NFS mount (with lockd), but can't
handle unlocking a locked file either at all, or in anything like
real-time. So if your Debian system is NFS mounting /var/spool/mail
from a box with this problem, you'd better not even *think* about
using lockf on your mailbox. If you do, you may not see any new mail
ever again (or at least until the partition is unmounted and then
remounted).
I agree that this problem is total brain-damage, but it's out there
in the real world, and we have to deal with it. So, the prohibition
on using any locking mechanism other than .lock files is a good
thing.
--
M a l c . . . | "A wrong parameters may be caused the mainboard
(malc@thing.demon.co.uk) | out of order." -- Pentium motherboard manual.
Reply to: