Message132330
| Author |
tim.golden |
| Recipients |
asvetlov, brian.curtin, flox, jafo, jaraco, loewis, ncoghlan, pitrou, r.david.murray, techtonik, tim.golden |
| Date |
2011年03月27日.14:23:36 |
| SpamBayes Score |
0.00010184726 |
| Marked as misclassified |
No |
| Message-id |
<4D8F4858.1020001@timgolden.me.uk> |
| In-reply-to |
<1301235281.56.0.933417549361.issue7443@psf.upfronthosting.co.za> |
| Content |
For clarity, while making unlink more robust is no bad thing, the error occurs when the unlink *succeeds* but a subsequent create of the same name fails. This happens when an indexer, Virus scanner or TortoiseSvn etc. has opened the file with SHARE_DELETE. This allows a DeleteFile to succeed but continues to hold an open handle on the file. A following test which uses an identically named file (such as the global TESTFN) will fail if not enough time has elapsed for the background process to release its handle. A good candidate to see this in action is the test for tarfile.
I did start to undertake a conversion of TESTFN to a named temporary, but it started to sprawl all over the place and came up against a number of corner cases (eg where tests deliberately wanted two filenames to be the same) so I gave up. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2011年03月27日 14:23:40 | tim.golden | set | recipients:
+ tim.golden, loewis, jafo, jaraco, ncoghlan, pitrou, techtonik, r.david.murray, brian.curtin, asvetlov, flox |
| 2011年03月27日 14:23:37 | tim.golden | link | issue7443 messages |
| 2011年03月27日 14:23:37 | tim.golden | create |
|