how winnt fileops work and what to do about it (was Re: [Twisted-Python] Twisted windows hackers - help the tests to pass!)
Jean-Paul Calderone
exarkun at divmod.com
Sat Dec 31 16:52:30 EST 2005
On Sat, 31 Dec 2005 05:48:43 -0500, Paul G <paul-lists at perforge.com> wrote:
>
>ok, i can actually chime in here because i've done filesystems work on
>windows (don't ask ;). now, it's been a while, but i should remember things
>reasonably accurately (i hope). see below for comments:
Thanks, Paul, for these comments. This cleared up a lot about how the filesystem works on Win32 for me.
> [snip]
>
>1. change the offending code not to do this rename
>2. instead of a rename, create a new directory, do a recursive copy into it
>from the original and retry removing the original directory asynchronously
>until it succeeds. obviously, the file handles which are open at that point
>will be referencing a different copy of the files from the ones which will
>be opened subsequently.
>3. test whether the zwDeleteFile() behaves in the way i conjrectured it to
>(wrt files or directories). if so, cause it to be implemented in the pywin32
>extension and use it to perform the delete.
>4. test whether you can either use ZwSetFileInformation() to rename
>directories by changing the FILE_NAME attr in the appropriate info structure
>or use it to move by renaming files which are open, again using the
>appropriate (but different) structure.
>if so, implement this or cause this to be implemented in pywin32. it is
>unclear (to me) whether this would result in the pre-move file handles being
>dead, stale or correct.
>5. instead of opening the files as normal, open them with pywin32's
>implementation of CreateFile(), specifying the appropriate sharemode. this
>will allow the rename (move really) to go through, but it is unclear what
>happens to the preexisting filehandles.
>6. implement, or cause to be implemented, CreateHardlink() in pywin32.
>create a new directory and recursively hardlink contents of the original
>into the new directory. asynchronously retry recursive deletion of the
>original one.
To these, I would insert a few questions to be answered first:
0. Are the test_output and test_runner tests attempting to move the top-level _trial_temp, or an identically named directory somewhere inside it?
1. Why are the tests trying to move the _trial_temp directory aside at all?
2. If there is a legitimate reason for #1, what files remain open in _trial_temp which are preventing the move from succeeding?
Jean-Paul
More information about the Twisted-Python
mailing list