This is an issue with dot locking that I brought up about two years ago,
but apparently never opened a bug for. This change in behavior is a
good reason not to use dot locking as the default.
I just opened a bug report for it:
https://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=14977
I have been successfully using lockf locking over NFS for a couple
years.
Dot locking is the only kind of locking guaranteed to be `supported' on
all/most servers, so I don't see how any other default is sensible.
Maybe I'm misunderstanding something.
Isn't it common knowledge that lockf() is not entirely portable?
Nmh does not live in a SVR4/POSIX-only world.
Anyway, I think the best might be for nmh to refuse to manipulate (create,
edit, etc.) files that it cannot dotlock. I'm not sure whether that
refusal should be a fatal error for the entire command being executed,
or a warning and partial success of the command.
Either a fatal error or a warning would have save folks
from confusion and unhappiness.
But also: is there some compelling reason to lock aliases
files before they are read? I can't think of one.
steve
- - -
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers