Re: [Nmh-workers] Lock gone mad

[Valdis . Kletnieks]

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.

pgplSJwK2oHAD.pgp
Description: PGP signature