[prev in list] [next in list] [prev in thread] [next in thread] 

List:       c-client
Subject:    Re: imapd changing ctime
From:       Mark Crispin <mrc () CAC ! Washington ! EDU>
Date:       2005-04-11 18:51:25
Message-ID: Pine.LNX.4.63.0504111134310.29380 () shiva1 ! cac ! washington ! edu
[Download RAW message or body]

On Mon, 11 Apr 2005, Rob Henderson wrote:
> We have observed that the UW imapd is changing the ctime on mail folders
> 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.
[prev in list] [next in list] [prev in thread] [next in thread]