> > 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 [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
