Subject: bug? mail lost in space with mbox and disk full

From: Tomas Kullman - ICL ProSystems AB <[email-masked]>
Date: Mon, 21 Nov 1994 20:04:38 +0100

imap-3.5 compiled for sun with EXTRADRIVERS=mbox
daemon version: IMAP2bis Service 7.8(92)

We have discovered a potential dangerous bug? (feature?) in the
mbox driver. We use an imapd compiled with mbox driver enabled.
When opening INBOX with newly arrived mail in the system
maildrop and mbox file exists in $HOME, all or part of new mail
will be lost or truncated if the transfer operation from maildrop
to $HOME/mbox fails to complete due to lack of space on storage
device (disk). There is no way to recover. BAD!
Tracing the code reveals a returned error ENOSPC (No space left
on device) from fsync() but seem to be ignored. Even when reading
the source it is hard to figure out who's fault it is, the mbox
code or the (Sun)OS system call implementation. Obviously the
write() system call done just before fsync() had a normal return.
By laborating with different sizes of incoming mails I found out
that 60k mail gave a behavior that restored the system maildrop
(write() return an error) while 12k were lost or truncated. Ahhh,
I forgot: I tested both 0k and 8k space left on disk. Something
in the (Sun)OS swallows 12k even if there is no space left on disk.
A reasonable fix could be to care about the return code of fsync()
system call and apply the same recovery as for a failing write().

By the way, Is this something the IMAP and/or c-client community are
already aware of?

Cheers,
--
Tomas Kullman, ICL Prosystems AB, Sweden

---

From: Mark Crispin <[email-masked]>
Date: Mon, 21 Nov 1994 23:52:38 -0800 (PST)

This problem only occurs when ~/mbox is accessed via NFS.  This was dealt with
in the other c-client modules some time ago, but not in the mbox driver (we
don't use it here -- basically, I forgot).  Once again, NFS' failure to
implement UNIX filesystem semantics correctly comes back to haunt us.  The
latest imap-3.6.BETA fixes this problem.  Thank you for reporting it.

By the way, it isn't necessary to sent bug reports to the c-client list.  I'd
like to keep the c-client list low volume and low noise; it'd be neither if
every bug report ends up being posted here.  I'd hate to see a fixed bug
become part of ``folklore''.

So, please send bug reports to me, and complain to the c-client list only if
you don't get any satisfaction...  ;-)  I try to fix bugs within a day or two
of the report.

-- Mark --