Date: Fri, 1 Nov 1996 12:57:35 -0800 (PST) From: Mark Crispin <MRC@CAC.Washington.EDU> To: John Fieber <jfieber@indiana.edu> Cc: chat@freebsd.org Subject: Re: /var/mail SUMMARY Message-ID: <MailManager.846881855.21860.mrc@Tomobiki-Cho.CAC.Washington.EDU> In-Reply-To: <Pine.BSI.3.95.961101140827.13075A-100000@fallout.campusview.indiana.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
John, Good summary!! On Fri, 1 Nov 1996 14:56:30 -0500 (EST), John Fieber wrote: > 1) For safety purposes, it is best for any process mucking with a > user's mailbox to use *all* locking mechanism supported on the > platform. Agreed. > 2) For a variety of debatable reasons, the standard mail spool > policy in FreeBSD does not support .lock file locking. Agreed. > 3) Mark Crispin's software apparently assumes that .lock file > locking is available on all platforms and thus encounters some > problems on FreeBSD. Slight rewording: 3) Mark Crispin's software assumes that .lock file locking should be attempted on all platforms on the grounds that it is impossible to know when it is needed and when it isn't. The software outputs a warning message when it can not do .lock file locking, unless that message is quelled. That message is not quelled by default on FreeBSD (or on any other platform) because: 3a) NFS rathole 3b) sysadmin may install a different delivery agent (how do we know?) 3c) multiplatform interoperability is of paramount importance There seems to be considerable controversy about (3a) and (3c); many individuals dismiss both of these. I do not have that luxury; no matter how much flamage I may receive from the FreeBSD community, the people who sign my paychecks will not permit me to abandon either of these. I remain bewildered why the FreeBSD community can not make due with a technote of the form: c-client, which is used by IMAP, Pine, and other software, is distributed with a conservative multi-platform configuration that causes an extraneous warning on most FreeBSD systems. Unless you are using NFS to access mail, or you have changed the local mail delivery agent, you should build this software with -DIGNORE_LOCK_EACCES_ERRORS to quell that warning message. > 4) The meat of the debate is if and how the software should > determine the available locking mechanisms. I gather that .lock > file support is currently configured at compile time. Agreed. The argument boils down to which is the better default: 4a) do what works, and is least obnoxious, for most FreeBSD sites 4b) do what is least likely to cause undetected failure As software developer, I choose to ship with the (b) default, under the assumption that a site that wants (a) and understands the possible adverse consequences can figure out how to switch to (a). Prior to imap-4, I did (a), and was badly burnt. The FreeBSD community has been the only one that has advocated a return to (a). In every other case reported to date, the warning meant that real locking failures were happening. Most of the customers want us to guarantee that the software is, and always will be, setgid-safe. We've resisted that. > 5) Most of this thread has been about mail spool policy which has > little if anything to do with the issue at hand of detecting > supported locking mechanism in an accurate and unobtrusive way. Agreed. I believe that there's no portable way to detect the supported locking mechanism, especially *not* on a per-file basis (which it needs to be once NFS rears its ugly head). SCO and other vendors agree, and follow the "apply all possible locks" position too.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MailManager.846881855.21860.mrc>