Subject: imapd changing ctime

From: Rob Henderson <[email-masked]>
Date: Mon, 11 Apr 2005 13:23:51 -0500

We have observed that the UW imapd is changing the ctime on mail folders
on every access, even when the folder is not modified.  This ends up
causing a bad interaction with our incremental backups which are based
on ctime rather than mtime.  For example, we have a number of users with
very large archived mail folders that haven't been modified in years.
However, they are frequently accessed for reading via imap.  Every time
they are accessed, the ctime changes so they are being backed up during
the incremental backups.

I'm trying to understand why imapd would need to modify a folder's ctime
like this and to find out if I can make it stop doing this.

Thanks for your help!

	--Rob
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Mon, 11 Apr 2005 11:51:25 -0700 (PDT)

On Mon, 11 Apr 2005, Rob Henderson wrote:
> on every access, even when the folder is not modified.

Fair question, unfair answer.  :-)

Blame the designers of UNIX.  There is no way to "peek" at the contents of 
a file without changing either the atime or the ctime.

If atime is changed, then checks for new mail based on atime will get 
false negatives.  If after a peek you restore the atime to its previous 
value, the ctime gets changed as a side effect.

One of the design goals of the new mailbox format we have under 
development is to address the backup problem.  Since the underlying 
problem occurs with having mailbox metadata in the same file with message 
data, the only way to solve the problem is to split mailbox metadata into 
a different file.

So, help is on the way, but there's no short-term solution.  If you break 
imapd's changing of ctime, then you'll break new mail checking.

You could try to convince the UNIX geeks of the world that their notion of 
file dates is wrong-headed, and that it should be possible for an 
application to peek at a file without altering its metadata in any way. 
Point out that, because of this UNIX design bug, backup applications (such 
as dump) kludge around this by doing raw filesystem access.

However, I don't have much hope that you'll convince anyone, other than 
old farts like me who remember TOPS-20 and other systems which did file 
dates properly... :-(

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.