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.
