Author jdigital
Recipients asvetlov, brian.curtin, flox, jafo, jaraco, jdigital, loewis, ncoghlan, pitrou, r.david.murray, techtonik, tim.golden
Date 2011-04-01.21:08:51
SpamBayes Score 3.14065e-12
Marked as misclassified No
Message-id <1301692132.39.0.171681232066.issue7443@psf.upfronthosting.co.za>
In-reply-to
Content
> * Patch Py_DeleteFileW in posixmodule.c so that it renames before
> deleting: should solve the problem overall but obviously has a
> possible wider impact, in general and on performance in particular.
> This rename might be a simple rename-to-guid or something more
> sophisticated such as the rename-to-recycler which cygwin uses.
> 
> * Patch support.unlink in the test package to do the rename dance on
> the basis that it'll fix at least some of the problems with less
> impact overall.
> 
> Opinions? I'm willing to do either.

I vote for fixing the test package.

File system "extensions" may track and record this activity.  To use DropBox as an example, doing the rename and delete will cause the renamed and deleted file to be recorded.

Just my opinion, but the code path to delete a file should be as short as possible.  Making lots of other OS calls just doesn't seem right.

I understand the wish to have a reliable unlink call but I'd be uncomfortable with a workaround that may be visible around the edges.
History
Date User Action Args
2011-04-01 21:08:52jdigitalsetrecipients: + jdigital, loewis, jafo, jaraco, ncoghlan, pitrou, techtonik, tim.golden, r.david.murray, brian.curtin, asvetlov, flox
2011-04-01 21:08:52jdigitalsetmessageid: <1301692132.39.0.171681232066.issue7443@psf.upfronthosting.co.za>
2011-04-01 21:08:51jdigitallinkissue7443 messages
2011-04-01 21:08:51jdigitalcreate