> Back in Dec. I posted some messages about getting dmail and procmail
> to work together to deliver to MBX mailboxes in ~/INBOX. I've since
> gotten that working but have recently notice that I've been getting
> some mailbox corruption in user's mailboxes. My question is, is dmail
> quota safe when delivering to mbx mailboxes?
Yes, dmail (as with all other c-client applications) is supposed to be
quota-safe. If it is unable to write to the mailbox, it will back out of
the append and restore the mailbox to the previous state.
Note that this will happen on a hard quota limit (a write failure), not a
soft quota limit.
Make sure that you have the latest version. There were issues on SVR4 and
TRU64 UNIX in older versions. In particular, a bug in one of the TRU64
filesystem types got tickled by the sequence of system calls used in the
older version, resulting in nulls being written instead of the actual
Since you say that you're running Linux, neither of these issues should
apply. On the other hand, I don't have much experience with the Linux
implementation of quotas; most people just throw enough disk on Linux
Quote:> On the imap client end, users who get corrupt mailboxes are greeted
> with this message when trying to login:
> IMAP protocol error: command unrecognized: "SEARCH ERRFLG = 2"
> Unknown on line 0
> Command unrecognized: "SEARCH ERRFLG = 2"
> Unknown on line 0
I haven't a clue as to what this means. "SEARCH ERRFLG = 2" is certainly
not a valid IMAP protocol command, nor is this anything that would be
babbled by UW imapd.
Quote:> On the server side, running pine as the user results in an error
> message about bad UID's in the mailbox. Pine tries to repair the
> mailbox, but is unable.
What precisely is the message, and more importantly, what is the final
message issued by Pine before it is "unable". The bad UID messages are
generally just warnings; it's the last message that says what really
Quote:> Examining ~/INBOX directly reveals a ^M at the
> end of each line.
This is correct. mbx format uses Internet newlines, not UNIX newlines.
This means that the server doesn't need to do newline conversion nor do
Quote:> Should dmail be able to correctly handle quotas? If a
> message is being written to a mbx mailbox and the hard quota is
> reached in mid-message write, will the the integrity of the mailbox be
Yes, and yes. If not, and you have the latest version, then you have
found a bug and I am very interested in the details.
One problem with dealing with quotas is that there are multiple
implementations, each with different characteristics. One *
implementation that I once encountered set a bit on an open file
descriptor when a quota exceeded error was hit, and once set it refused to
allow any other operations including file-truncate!
However, it seems to me that you're talking about soft quota, not hard
quota. As far as the c-client library is concerned, hard quota is the
only thing that exists; the presumption is that the quota system will
produce an appropriate snarl. The UW computer center has a local patch to
UW imapd that, in conjunction with the local quota and accounting system,
presents the quota snarl as an IMAP alert. That patch isn't in the
distributed version since it's highly dependent upon our local accounting
system and (ugh!) AIX.
Quote:> Are there non-quota scneraios in which mailbox corruption
> can occur? (Perhaps I have something misconfigured.)
Access via NFS or other network filesystem is the most significant
problem. Besides the locking issues, mbx format assumes that the inode
and data are updated atomically and instantaneously. This happens with
local files, but over NFS there is a timelag and more importantly the
inode and data are updated independently. Modern versions of NFS have
reduced this problem, but it has not gone away entirely.
Quote:> I'd like to find out what's causing this problem
> rather than picking up the pieces after it occurs.
As would I.
-- Mark --
Science does not emerge from voting, party politics, or public debate.