Issue 7360: [mailbox] race: mbox may lose data with concurrent access (original) (raw)

Created on 2009-11-19 16:20 by doko, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
mailbox-race.py doko,2009-11-19 16:20 test case
Messages (7)
msg95487 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2009-11-19 16:20
[forwarded from http://bugs.debian.org/451733] the mailbox._singlefileMailbox class is not safe with concurrent access, because mailbox._singlefileMailbox.flush() replaces the underlying file with a new copy by constructing a temporary file and then renaming it. This breaks all other class instances which have this mailbox open. I'm attaching a script demonstrating the problem. I think it's a bad idea to use rename(2) here; overwriting the file content would fix the race condition, and #451274 too[1].
msg95491 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-11-19 16:52
> the mailbox._singlefileMailbox class is not safe with concurrent access, > because mailbox._singlefileMailbox.flush() replaces the underlying file > with a new copy by constructing a temporary file and then renaming it. > This breaks all other class instances which have this mailbox open. I don't think this class aims at being safe against concurrent access, so having it fail loudly is a good thing. Besides, the proposed cure (overwriting instead of renaming) looks worse than the illness. The virtue of renaming is that it is atomic (on POSIX systems at least), so you can't end up with a half-written mailbox if there's a crash or an IO problem in the middle.
msg95494 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-11-19 17:06
Oops, sorry: > I don't think this class aims at being safe against concurrent access, > so having it fail loudly is a good thing. I now understand that the problem is that it doesn't fail loudly. That's what I get for replying too quickly. Still, I don't think the suggested fix is ok. Perhaps we should simply state in the documentation that flush() discards the old file, so that other processes accessing it may get a surprise.
msg95496 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-11-19 17:18
Actually, the doc is quite clear about it: « Be very cautious when modifying mailboxes that might be simultaneously changed by some other process. The safest mailbox format to use for such tasks is Maildir; try to avoid using single-file formats such as mbox for concurrent writing. »
msg163109 - (view) Author: Petri Lehtinen (petri.lehtinen) * (Python committer) Date: 2012-06-18 17:40
Can this be closed?
msg163111 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-06-18 18:19
Probably. Unless I'm mistaken, the issue with concurrent rewrite (as opposed to append) exists for single-file-mailboxes in the general case, not just in Python. And as far as I know failure is never noisy, the last writer wins.
msg164048 - (view) Author: Petri Lehtinen (petri.lehtinen) * (Python committer) Date: 2012-06-26 06:38
I created #15122 for adding an option to rewrite the contents of single-file mailboxes in-place. Closing this issue as wontfix.
History
Date User Action Args
2022-04-11 14:56:54 admin set github: 51609
2012-06-26 06:39:01 petri.lehtinen set status: open -> closedsuperseder: Always rewrite single-file mailboxes in-placemessages: + resolution: wont fixstage: resolved
2012-06-18 18:19:31 r.david.murray set nosy: + r.david.murraymessages: +
2012-06-18 17:40:47 petri.lehtinen set nosy: + petri.lehtinenmessages: +
2009-11-20 01:34:56 pitrou set nosy: + akuchling
2009-11-19 17🔞28 pitrou set messages: +
2009-11-19 17:06:45 pitrou set messages: +
2009-11-19 16:52:18 pitrou set nosy: + pitroumessages: +
2009-11-19 16:20:41 doko set files: + mailbox-race.py
2009-11-19 16:20:21 doko create