> >> configure should be able to set this on a per-platform basis. > > It can't because it depends on what other applications use. > > Fedora /bin/mail uses fcntl and Mutt recommends it. > procmail can use it. I haven't had any problems since I > starting using fcntl. I did see problems with dot locking, > I expect because other applications weren't using it.
As Ken mentioned earlier, there are two types of locking at issue: 1) System mailbox locking This must use the same scheme as the platform's /bin/mail and friends use. The configure script needs to set the appropriate value based on the platform it's being run on. Configure also needs to determine whether inc needs setgid on that platform. The user should never have to override these, and I don't think we should even provide a knob to let them to do so. 2) nmh internal locking This can be whatever makes the most sense for nmh itself. Again, configure should have knowledge to set this to a reasonable platform-specific setting. My guess is it would default to flock, with platform specific overrides where it's known flock doesn't play nice. This one definitely needs a knob to allow the user to override the default. The reason to shun fcntl locking is this (from SUS v3): All locks associated with a file for a given process shall be removed when a file descriptor for that file is closed by that process or the process holding that file descriptor terminates. Locks are not inherited by a child process. This means that dup()ing a descriptor to a locked file, and then closing either of those fd's will kill *all* locks on that file, no matter which fd they were acquired on. This can wreak havoc when you have library routines that are doing file descriptor manipulations behind the scenes. And beware flock on Solaris, which is just a wrapper around fcntl. --lyndon _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
