On Thu,  5 May 2011 19:04:16 +0200, R. David Murray wrote:
> "prepare new tail" means all of the text from the first modified
> line to the end?  (As opposed to "just the new mail"?) mailbox
> does locking.  I see no reason in principle it couldn't
> stat/restore, it would just be setting the times on the new file
> rather than on a truncated/rewritten old file.  How hard that
> would be to incorporate into the existing logic I have no idea.
> Of course there may be issues about this I haven't thought of.

Me too and even more.
Clearly mailbox.py cannot do any dotlocking due to missing
permissions, so this is silently ignored to be able to proceed at
all.  Therefore only fcntl/flock locking is used for
a /var/{spool/}mail box by mailbox.py.  This is fine as long as
all programs agree in locking such a file in the usual way, that
is, use both, dotlocking *and* flock/lock, and restart from the
beginning if one of them fails due to another program holding that
very lock.  mutt does that but i won't do any bet here.

And then the signal handling, and Python even supports threading,
and it is embeddable and there may be third-party modules also
involved.  This is the Death Valley of programming.

    $PYP mb.flush()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/Users/steffen/usr/opt/py3k/lib/python3.3/mailbox.py", line 659, in flush
        new_file = _create_temporary(self._path)
      File "/Users/steffen/usr/opt/py3k/lib/python3.3/mailbox.py", line 2061, in _create_temporary
        os.getpid()))
      File "/Users/steffen/usr/opt/py3k/lib/python3.3/mailbox.py", line 2051, in _create_carefully
        fd = os.open(path, os.O_CREAT | os.O_EXCL | os.O_RDWR, 0o666)
    OSError: [Errno 13] Permission denied: '/var/mail/steffen.1304628960.sherwood.local.37135'

So this seems to be the safest and most useful approach in this
context, because i do not want to imagine what happens if
something weird occurs in the middle of writing "the tail"
otherwise.  So i stop thinking about issue #7359.

> Do you think the mutt model is a good one to follow?

You mean resetting atime/mtime back to before the rename?
I don't like that and i don't understand it because the file has
been modified, so i think i would do (now,now) in that case
instead (because of the MMDF/MBOX newer==new mail case).
And in case a new mail has been inserted (now-2.42,now).