[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Lock gone mad

From: Valdis . Kletnieks
Subject: Re: [Nmh-workers] Lock gone mad
Date: Fri, 06 Apr 2007 14:40:13 -0400

On Fri, 06 Apr 2007 13:45:35 EDT, Ken Hornstein said:
> >Tell your vendor to rebuild the package with fcntl locking.  nmh uses dot
> >locking by default, which is pretty brain dead.  Here is the option they
> >should give configure:
> >
> >--with-locking=fcntl
> >
> >So the question becomes, is there a reason we shouldn't fix configure to
> >use fcntl locking by default, and only fall back to dot locking if fcntl
> >locking isn't available?
> It does boggle the mind why /dev/null is being locked _at all_.  I did
> try to track this down once, and it was a maze of functions ... I was
> running low on time and I just switched to fcntl locking, but seriously
> this probably should be fixed.

I remember chasing this down once upon a time as well, because it gave
exmh indigestion at startup.  it was this crud in uip/scansbr.c:

    if (outnum) {
        if (outnum > 0) {
            scnmsg = m_name (outnum);
            if (*scnmsg == '?')         /* msg num out of range */
                return SCNNUM;
        } else {
            scnmsg = "/dev/null";

And later on, code assumes that scnmsg points at a mail file that needs to
be scanned.. so it locks the file totally oblivious to the fact it's not a
mail file under ~/Mail/ - whoops.. ;)

(I forget how that code got called with a negative number in outnum, but
it was some fairly easy to trigger condition....)

The reason dot locking is the default is because until fairly recently,
fcntl locking wasn't a trustable option over NFS.

Attachment: pgplSJwK2oHAD.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]