[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.
pgplSJwK2oHAD.pgp
Description: PGP signature