[Nmh-workers] MHCONTEXT buglet - send, post slow with dot_lock

[Robert Tarrall]

On a Linux system where I just upgraded from nmh-1.0.4 to nmh-1.1RC3,
sending takes a long, long time (circa 30 seconds) from the time you
type "send" at the whatnow prompt to the time you get a command prompt.

It appears that 'post' was trying to dotlock /dev/null, which meant it
was trying to create /dev/null.lock, which obviously didn't work.

Adding a 'context: <filename>' entry to my .mh_profile fixed this -
however note that if $MHCONTEXT isn't defined and there's no context
entry in your .mh_profile it's supposed to default to <nmh-dir>/context
so in theory I shouldn't have needed to do this.

There are a couple of bugs reports that appear relevant; does not appear
that the folks who filed the bugs were aware that adding a context entry
to mh_profile is a workaround...
http://savannah.nongnu.org/bugs/?func=detailitem&item_id=7917
http://savannah.nongnu.org/support/?func=detailitem&item_id=103005

Also appears that some people might explicitly set $MHCONTEXT to
/dev/null:
  http://lists.gnu.org/archive/html/nmh-workers/2003-10/msg00014.html
and again this is a problem since you end up trying to dotlock where
you don't have permissions to do so.

Support item 103005 (link above) includes a patch to sbr/lock_file.c
which simply skips locking if the file is /dev/null.  That's one
solution... a more general solution might be to skip locking if
permissions won't allow the lock file to be created.

I've spent some time looking at the code but I'm not 100% sure where
this happens - I *think* it's due to sbr/context_foil.c but not
positive.

Mostly wanted to note this issue in the mailing list so if anyone knows
a fix they can post it, and also so that folks who run across this
themselves can work around it by changing their mh_profile.

                       -Robert Tarrall.-
                       Unix System/Network Admin
                       E.Central/Neighborhood Link