Re: maildir in Gnus vs. clock corrections and PID recycling

[prj@po.cwru.edu (Paul Jarc)]

Matthias Andree <ma@dt.e-technik.uni-dortmund.de> wrote:
> Mail reading means moving the file from new/... to
> cur/<time>.<unique>.<hostname>,<flags>.

Actually, it's cur/<time>.<unique>.<hostname>:<flags>.

> What does nnmaildir.el and possibly other maildir code in Gnus do when
> it is about to move a mail from new/ to cur/? Does it rely on uniqueness
> and will it -- as mutt -- accidentally kill an already-present file in
> cur/?

Yes.

> The supposedly later http://cr.yp.to/proto/maildir.html refines the
> documentation, and demands that the middle part does not recur within
> one second, which is still insufficient given that a computer clock
> might be stepped back,

Stepping a clock backwards produces so many problems that it is better
to ignore those problems, run the clock monotonically, and find a
different way to deal with any problems that stepping backwards was
supposed to solve.

> It seems that Postfix, Courier and Maildrop will settle on using the
> tmp/* file inode number for the <unique> part in new/, so these
> applications will rename from tmp/time.pid_count.hostname to
> new/time.inode.hostname.

That sounds like a good idea.  As long as all maildir writers do that,
readers (programs that move messages from new/ to cur/) won't have to
be changed.  nnmaildir does deliver new messages to tmp/ sometimes, so
I'll change that.  But the problem isn't likely to affect nnmaildir
anyway, since Emacs is long-lived and nnmaildir is not likely to
deliver new messages within 1 second of Emacs starting or exiting.


paul