This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sdaoden
Recipients belopolsky, r.david.murray, sdaoden
Date 2011-05-05.16:38:38
SpamBayes Score 3.7195897e-09
Marked as misclassified No
Message-id <20110505163830.GA1595@sherwood.local>
In-reply-to <1304610424.6.0.254596604566.issue11935@psf.upfronthosting.co.za>
Content
After half an hour of shallow inspection.

mutt really modifies mailbox files in place (mbox_sync_mailbox())
after creating (all the new tail in) a temporary file.  Then
seek()/write()/truncate() etc..  It however has mutt_dotlock(1)
and it does block signals and it is a standalone program and thus
i don't think this behaviour can be used by Python.

In respect to our issue here i must really admit that mutt does:

    prepare new tail
    stat box
    modify box to incorporate tail
    close box
    utime box with stat result times
    reopen box

So actually the result looks as if it never has been modified.
But maybe it is because like this it is in sync with the standart,
since strictly speaking there is no *new* mail in the box.

Unless you vote against it i'll write a patch tomorrow which will
use a state machine which only triggers the utime if some kind of
setitem has occurred.  I can't help you to overcome your malaise
against soiling an atime's pureness.
'Really want a future date??
History
Date User Action Args
2011-05-05 16:38:41sdaodensetrecipients: + sdaoden, belopolsky, r.david.murray
2011-05-05 16:38:38sdaodenlinkissue11935 messages
2011-05-05 16:38:38sdaodencreate