Shaun -
There are two things going on:
The first thing is that in recent versions of the Linux kernel, the
developers of Linux have "improved" the flock() system by changing the
definition of how flock() works on network filesystems such as NFS.
The traditional definition, for the past 20 or so years, has been that
flock() on a network filesystem is a successful no-op. The recent
"improvement" in Linux is that doing so always returns ENOLCK.
Suffice it to say that there have been howls of protest from application
developers who have depended upon the traditional behavior for the past
two decades. The answer has been a Stallmanesque "the new version is
better, fix your software."
The effect of this incompatible change to flock() is that attempts to
upgrade a shared lock to an exclusive lock on an NFS file always appear to
fail due to some other process having a shared lock. In reality, neither
a shared lock nor an exclusive lock is acquired.
This is what that strange "8" flag that you observed means: the message is
expunged, but the space could not be reclaimed because (imapd falsely
believed that) some other session had the mailbox opened. It will reclaim
the space when it can lock the mailbox exclusive (which will never happen
because of the incompatible flock() change).
I discovered the problem after imap-2004d was released. The necessary
workaround is in imap-2004e:
ftp://ftp.cac.washington.edu/mail/imap-2004e.DEV.tar.Z
Although this is presented as a development snapshot, this version is
really just imap-2004d with a small number of limited-audience but
critical changes since imap-2004d. Put another way, it's safe to install
in place of imap-2004d.
The second thing that is going on was alluded to above. I don't know much
about GFS, but it seems to be that for the purposes of flock() locking
that it is a type of network filesystem. As such, it is not suitable for
the mbx format; shared access and locking can not work on such systems and
you *will* have mailbox corruption.
Put another way: the mbx format *MUST* be on a local filesystem that
supports flock() and instantaneous (and atomic) update of data and inode
data across all sharers.
The corrolary to this is that you can't use mbx on your GFS filesystem;
and as you have noticed corruption will result.
Some "experts" will claim that the "fix" for this problem is to use
fcntl() locking. It's a long story why not; so trust me, you do not want
to do this.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
