On Wed, 8 Nov 2006, Andrew Laurence wrote:
It occurs to me that part of the disconnect apparent in this thread
is the assumption about what's operating as the NFS *server*. Mark's
posts seem to indicate an assumption that (often?) Solaris is serving
the NFS. (Mark, I apologize if you didn't mean to say that and I'm
getting that wrong.)
Nope. I'm referring to the problems of Solaris as the NFS *client*.
We've been using NetApp as our NFS server(s) for so long that,
frankly, I was quite puzzled to see discussions of SRV4 issues in an
NFS conversation.
If the client is not SVR4, then all the stuff about fcntl() locking can be
ignored. flock() locking is used on any system which has it (basically,
everything except SVR4 and OSF/1), and flock() is a no-op on NFS.
The problem becomes much simpler to explain then:
There is no locking over NFS, therefore formats which depend upon locking
(e.g., mbx and mix) are unsafe to use over NFS.
There is no locking over NFS, therefore there is only .lock file locking
in traditional UNIX format. There is therefore no protection against more
than one session opening the same mailbox at a time. Usually (the 98%
case) when this happens, one session or the other will detect that the
mailbox file has changed in an unexpected way, and that session will kill
itself (discarding any unsaved flag changes) without causing mailbox
corruption. The worry is the 2% case, and the fact that corruption in
traditional UNIX mailbox files that is not observable in the first line of
the file will not be detected.
Note that .lock file locking requires either that the spool directory be
protected 1777 (the recommended setting) or that the mlock program (part
of the UW IMAP toolkit) be deployed. By default, many systems have
neither; this in turn means that .lock file locking is disabled. There is
a warning ("Mailbox vulnerable") when this happens, but some third-party
redistributions delete this warning in the incorrect assumption that it is
"unnecessary".
If both locking and .lock files are disabled, then there is no protection
against mail delivery happening while imapd is doing something to the
mailbox. The result is lost mail and/or mailbox corruption.
Many sites have run for an extended period of time in this way, and just
attribute user complaints to "user error" or "flaky software." This has
been a particular problem on those sites where the "Mailbox vulnerable"
warning is disabled.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
