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
Sat Dec 31 16:52:30 EST 2005

On Sat, 31 Dec 2005 05:48:43 -0500, Paul G <paul-lists at> 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?


More information about the Twisted-Python mailing list