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 Jim.Jewett
Recipients Jim.Jewett, ajaksu2, akuchling, baikie, barry, loewis, nnorwitz, peter.ll, petri.lehtinen, r.david.murray, terry.reedy
Date 2014-03-19.01:20:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1395192048.22.0.483989040839.issue1599254@psf.upfronthosting.co.za>
In-reply-to
Content
OK, if I understand *that* correctly,

(1)  The locking mechanism doesn't really work, and that is too complicated to fix in this issue.  A new issue would be fine.

(2)  The locking failure messes up the Table Of Contents, but that is too comprehensive a change to fix here, and should be handled in the new issue.

(3)  The locking failure also causes data loss/corruption in the messages themselves, and that *can* be fixed simply by truncate+append, instead of renaming.  (Is this actually true, or only true if you *also* implement better change-detection to catch the other process?)

(4)  While the patches do (and test for) #3, there is not currently a patch that *only* does #3.

(5)  This is a pure bug fix; the only reason to change documentation would be to help make triggering the bugs less likely.

===

Also note that

(6)  At least some of the changes do seem to have been included at some point, so regenerating the patches is not mechanical.

(7)  The documentation has a big warning note, but the wording could use some improvement to emphasize that *even* reading is unsafe, if changes (even status changes, such as a "Seen" flag) could happen later.  Again, based on my possibly faulty understanding:

"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"

-->

"Keys may become invalid at any time, unless the mailbox is locked. 

Notably, another process may modify the underlying file storage so that the key used to retrieve an existing message becomes invalid, or points to a different message.  To prevent this, a mailbox must be locked prior to even reading a message, and must not be unlocked until all changes -- even status changes, such as whether or not a Message was viewed -- for all keys have been completed and flushed."
History
Date User Action Args
2014-03-19 01:20:49Jim.Jewettsetrecipients: + Jim.Jewett, loewis, barry, akuchling, nnorwitz, terry.reedy, baikie, ajaksu2, peter.ll, r.david.murray, petri.lehtinen
2014-03-19 01:20:48Jim.Jewettsetmessageid: <1395192048.22.0.483989040839.issue1599254@psf.upfronthosting.co.za>
2014-03-19 01:20:48Jim.Jewettlinkissue1599254 messages
2014-03-19 01:20:45Jim.Jewettcreate