Re: Access denied when trying to move directory in use

Tech-Archive recommends: Fix windows errors by optimizing your registry

Hi Jeffrey,

Jeffrey Tan[MSFT] wrote:
Hi Corinna,

It seems that you are using undocumented Windows API ZwSetInformationFile
with FileRenameInformation parameter to move the files/directories. It

Sigh. I didn't even realize that this is an undocumented API until
you just told me. I hope you can understand my point here, though. The
idea is to have a generic delete/move operation which allows POSIX
delete semantics while maintaining a speedy operation in bulk remove
operations like the POSIX `rm -rf' case which consists of lots of
unlink/rmdir calls. The big advantage of using the ntdll API here is
the fact that the file has to be opened only once and the handle can
then be used for the whole operation. There's just no comparable win32
API to implement unlink/rmdir this efficient.

[...]
Have you tried this with more other directories? In this scenario, I
suspect the original code that uses the file may passed 0 as the
"ShareAccess" parameter, which does not share you to use
FileRenameInformation for the locking file.

If you look into the code snippets in my original posting, you see
that the other handle has been opened with all sharing flags set.
Also keep in mind that the second ZwOpenFile in the unlink code succeeded,
which means, there was an open handle, but that handle didn't disallow
sharing. It's the subsequent FileRenameInformation which fails with
STATUS_ACCESS_DENIED, not the ZwOpenFile.

Normally, you may use Process Monitor from the link below to monitor the
directory access of ZwSetInformationFile calling, there will be a "Access
Deny" record:
http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/processmon
itor.mspx
[...]

This was a very valuable hint, which actually solved my problem! I
didn't think of testing with other applications but while looking into
the output of Process Monitor I tried to move the file using Explorer
which, to my surprise, succeeded when using FileRenameInformation.

By comparing the different flags used by my unlink code and used by
Explorer, I found the cause of the problem. Apparently, the semantics
of FILE_DELETE_ON_CLOSE are different between files and directories.
When the directory is opened with FILE_DELETE_ON_CLOSE, then
FileRenameInformation fails. When the directory is not opened with
FILE_DELETE_ON_CLOSE, FileRenameInformation succeeds.

So, what my code basically does now is this:

ZwOpenFile (..., NO_SHARING, flags | (dir ? 0 : FILE_DELETE_ON_CLOSE);
if (open_failed)
{
ZwOpenFile (..., ALL_SHARING, flags | (dir ? 0 : FILE_DELETE_ON_CLOSE);
have_to_move = true;
}
if (have_to_move)
ZwSetInformationFile (..., FileRenameInformation);
if (dir)
ZwSetInformationFile (..., FileDispositionInformation);
ZwClose ();

Is there any chance to learn the reason why

open(delete-on-close);
move();
close();

works for files, but emits an access denied error in the move operation
on directories?


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
.