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 akuchling
Recipients
Date 2007-01-17.21:05:10
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
mailbox-pending-lock is the difference between David's copy-back-new + fcntl-warning and my -unified patch, uploaded so that he can comment on the changes.

The only change is to make _singleFileMailbox.lock() clear self._toc, forcing a re-read of the mailbox file.  If _pending is true, the ToC isn't cleared and a warning is logged.  I think this lets existing code run (albeit possibly with a warning if the mailbox is modified before .lock() is called), but fixes the risk of missing changes written by another process.

Triggering a new warning is sort of an API change, but IMHO it's still worth backporting; code that triggers this warning is at risk of losing messages or corrupting the mailbox.

Clearing the _toc on .lock() is also sort of an API change, but it's necessary to avoid the potential data loss.  It may lead to some redundant scanning of mailbox files, but this price is worth paying, I think; people probably don't have 2Gb mbox files (I hope not, anyway!) and no extra read is done if you create the mailbox and immediately lock it before looking anything up.

Neal: if you want to discuss this patch or want an explanation of something, feel free to chat with me about it.

I'll wait a day or two and see if David spots any problems.  If nothing turns up, I'll commit it to both trunk and release25-maint.



File Added: mailbox-pending-lock.diff
History
Date User Action Args
2007-08-23 14:50:04adminlinkissue1599254 messages
2007-08-23 14:50:04admincreate