Axel Thimm <Axel(_dot_)Thimm(_at_)physik(_dot_)fu-berlin(_dot_)de> writes:
the new release of procmail, v3.13.1, does not reset the access time on
alpha-dec-osf4.0b as did the prior released version. Locking stategies were
chosen the same as before:
Locking strategies: dotlocking, flock()
No errors can be found in the log files. Any ideas about that? (I came accross
this because my mail reader, mutt, depends on comaring access vs mod time to
indicate whether there is new mail in the mailboxes.)
As of version 3.12, procmail no longer forces an atime < mtime on a
mailbox when it's delivering to a previously empty mailbox. The other
possibility would be if you compiled procmail with NO_NFS_ATIME_HACK
defined.
Hmm, staring hard at it now, I suspect the test is reversed, and that
it should only be doing it [forcing atime < mtime] when the mailbox
_was_ empty, as the only file operation performed by procmail that
should update the atime of a mailbox is creat() or open() when the
mailbox did not previously exist.
Axel, for what mailboxes is the behavior of procmail version 3.13.1
broken? Is it on mailboxes don't exist before procmail creates them,
mailboxes that exist but are empty (zero size), mailboxes that exist
and have messages in them, or on some specific group of the above?
I've set the Reply-To: of this message to
procmail-dev(_at_)procmail(_dot_)org(_dot_)
All further discussion should take place there, please.
Philip Guenther