A.M. Kuchling added the comment: The bug got so complicated, with so many variations and failure modes, that I just lost track of what to do next.
Let's reboot. Problem #1 is that the single-file mailboxes subvert their own fcntl locking by writing to a temp. file and renaming; David's first patch takes care of that by truncating the original and copying. Problem #2 is that the mailbox classes keep an internal table-of-contents mapping messages to positions in the file. If some other process writes to the mailbox, this table-of-contents becomes obsolete, so we need to update it. But the ToC is also used to derive keys, the identifiers kept by scripts using the mailbox, so updating the ToC means these keys become invalid. And here's where I got confused: do we invalidate the ToC in all sorts of places? Or do we just document that you shouldn't trust keys to remain the same unless you've locked the mailbox? (Except this is only true for single-file mailbox formats - Maildir uses unique strings that don't change.) I suggest we apply the fix for #1, and for #2 just discard and update the ToC when we lock the mailbox, ignoring other possible routes to corruption (so no detecting the problem and raising an ExternalClash exception). Since 2007 the docs have said "If you’re modifying a mailbox, you must lock it by calling the lock() and unlock() methods before reading any messages in the file or making any changes". (I'm also reducing the priority of this bug; clearly it's not "high".) ---------- priority: high -> normal _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1599254> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
