At 12:25 AM -0500 2/14/08, Benjamin R. Haskell imposed structure on a stream of electrons, yielding:
On Wed, 13 Feb 2008, Bill Cole wrote:
[...]
Maildir DOES NOT require a timestamp in the filename, it's just common.
DJB's Maildir spec isn't RFC-esque (so it's not a MUST, in that sense). As far as I've seen, everything does what's described below. But, like you say, not a requirement. I think I skipped over the second and third sentences from this excerpt from http://cr.yp.to/proto/maildir.html (because of the first sentence) :
["" Unless you're writing messages to a maildir, the format of a unique name is none of your business. A unique name can be anything that doesn't contain a colon (or slash) and doesn't start with a dot. Do not try to extract information from unique names.
Okay, so you're writing messages. A unique name has three pieces, separated by dots. On the left is the result of time() or the second counter from gettimeofday(). ""]
Also note that that snippet expressly warns against doing what I said could be done (parsing the timestamp out of the filename).
Yeah, and I did a little more research and am now less sure that it is *safe* to not use the timestamp. I would not be shocked if something out there working with Maildir/Maildir++ requires it, given the fuzzy spec(s)
Incidentally, some other illuminating docs are:
http://www.qmail.org/man/man5/maildir.html http://www.inter7.com/courierimap/README.maildirquota.html
I'm curious: do you have examples of mail software that doesn't use the timestamp? (I could see some run-once script not doing it, but I'd be surprised if widely-used software didn't.)
The procmailrc man page says that MSGPREFIX defaults to 'msg.' but it
is not clear to me whether MSGPREFIX is used for Maildir delivery or
just for MH delivery. I've played it safe and use "MSGPREFIX=date +%s" but maybe that's not needed...
On my system, the timestamps in the filenames match the ctime, NOT the mtime:
~/Maildir/.Tagged/cur $ ls -lcrt |tail -1 -rw------- 1 wkc staff 13293 Feb 12 23:45 1202877918.P26840Q0M183345.toaster.scconsult.com:2,S ~/Maildir/.Tagged/cur $ ls -l 1202877918.P26840Q0M183345.toaster.scconsult.com\:2\,S -rw------- 1 wkc staff 13293 Feb 12 23:43 1202877918.P26840Q0M183345.toaster.scconsult.com:2,S ~/Maildir/.Tagged/cur wkc$ uepoch 1202877918 1202877918 is Tue Feb 12 23:45:18 2008
The earlier mtime matches the delivery time.
I think it'd generally be the case that the filename timestamp will match the *initial* ctime (before any possible ctime changes), since that should be synonymous with creation time. And, mtime could vary, because Dovecot syncs the mtime to the delivery time.
It seems that Dovecot maintains the mtime as the original delivery time of the message, i.e. delivery to the INBOX. It seems that Dovecot names files based on when the specific file (i.e. in that maildir folder/subdirectory) was created.
But, I still don't quite follow your example. Call the mailfile X (so I don't have to type it):
ls -lc X shows 23:45 - so, ctime = 23:45 ls -l X shows 23:43 - so, mtime = 23:43 And, the filename timestamp == ctime.
But, you say the mtime matches the delivery time.
Yes, it does.
So, the filename timestamp is two minutes *after* the delivery time?
Yes.
Did it take your LDA two minutes (or at least 1 min 19sec) to get the message from the MTA to the Maildir?
No.
It took 2 minutes for a MUA (Eudora) to see the message and tell Dovecot to move it to the "Tagged" IMAP folder (i.e. the .Tagged subdirectory)
Also, I think (but, maybe not on HFS+) there'd be a ctime change on renaming the file from X to X,S (adding the 'Seen' flag). Do you know whether that's the case?
(e.g. try:) touch foo ls -lc foo mv foo foo,S ls -lc foo
No need to touch, as I had a foo hanging around with a usefully aged ctime that would be visible if it changed:
~ $ ls -l foo -rwxr-xr-x 1 wkc wkc 332 Jan 29 03:32 foo ~ $ ls -lc foo -rwxr-xr-x 1 wkc wkc 332 Jan 29 03:32 foo ~ $ mv foo foo,S ~ $ ls -lc foo,S -rwxr-xr-x 1 wkc wkc 332 Jan 29 03:32 foo,S
Again, this is *HFS+* so it's goofy.
On Solaris UFS and VxFS 'mv' changes ctime. I'd bet on ext{2,3} behaving similarly.
[...] It looks like the use of ctime or mtime depends on wether you want the message removed x days after it was moved to say the trash folder (ctime) or will be removed x days after it originally arrived in the inbox (mtime). My personal opinion is currently that i would like it removed x days after it was placed in a certain folder, hence i use ctime.
Depends on the context for me. [... blah blah. Me blabbering...]
Again, that is FS-specific, and HFS+ is again a counter-example.
(one can argue that HFS+ is Bad and Wrong in many ways, but it is in widespread use...)
I guess the take-home message is that ctime isn't quite as consistent cross-filesystem as mtime. But, I still think ctime has its place in non-"Bad and Wrong" filesystems.
I think a case could be made to support the HFS+ behavior IFF you ignore 20 years of Unix FS behavior. #include applebugsme.h
The diversity of timestamps is useful to support a diversity of reasonable policies. It seems that Dovecot works to preserve the initial delivery time (as mtime) and that even on a filesystem where rename() does not update ctime, the way Dovecot handles MUA-initiated message moves assures that the ctime and the (new) filename both reflect the move time.
And, as Charles pointed out, in Dovecot 1.1 there's a plugin to do this. Does the expunge plugin work without the user logging in, though? (not that that's an enormous problem -- more curiosity)
A lot of this is mostly about curiousity...
--
Bill Cole
bill@scconsult.com