Author baikie
Recipients Jim.Jewett, ajaksu2, akuchling, baikie, barry, loewis, nnorwitz, peter.ll, petri.lehtinen, r.david.murray, terry.reedy
Date 2014-03-30.21:50:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20140330214954.GA14307@dbwatson.uk7.net>
In-reply-to <20140323225502.GA10247@dbwatson.uk7.net>
Content
On Sun 23 Mar 2014, David Watson wrote:
> There actually isn't a test for the original locking issue, as
> the tests all use the mailbox API, which doesn't provide a way to
> turn off dot-locking. ...

On second thought, the underlying error doesn't actually have
anything to do with locking - another process can open the
mailbox, and mailbox.py can replace the file before that process
even tries to lock it.  Andrew's test_concurrent_append()
originally *did* test for this, but commit c37cb11b546f changed
the single-file mailbox classes to just sync the file rather than
replacing it when messages have only been added, as in that test,
meaning it's no longer effective (for that issue at least).

I've now made a test for the original renaming-vs-copying issue
which just uses the simple _subprocess mechanism that the other
tests use, rather than trying to set up any special locking
conditions.  I've also split the tests into two patches -
mailbox-tests-2.7-part1-for-copy-back.diff has the test for the
original issue, and passes with the copy-back patch applied,
while mailbox-tests-2.7-part2.diff applies on top and includes
the rest (these involve the separate issues around rereading, and
mostly fail).
Files
File name Uploaded
mailbox-tests-2.7-part1-for-copy-back.diff baikie, 2014-03-30.21:50:08
mailbox-tests-2.7-part2.diff baikie, 2014-03-30.21:50:10
History
Date User Action Args
2014-03-30 21:50:13baikiesetrecipients: + baikie, loewis, barry, akuchling, nnorwitz, terry.reedy, ajaksu2, peter.ll, r.david.murray, petri.lehtinen, Jim.Jewett
2014-03-30 21:50:12baikielinkissue1599254 messages
2014-03-30 21:50:11baikiecreate