Prev: RasEditPhoneBookEntry and Vista
Next: GetCurrentHwProfile determining dockability on Vista
From: Don Burn on 29 Jan 2007 08:16
ZwSetInformationFile is documented for the DDK. The FltXXX calls are only
for mini-filter drivers. The kernel has the rule that it will not remove a
link which may be an anscestor path component of any open file. So it is
unlikely you are going to get this to work.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply


"Corinna Vinschen" <corinna(a)community.nospam> wrote in message
news:epfbb7$iie$1(a)perth.hirmke.de...
> Corinna Vinschen wrote:
>> Jeffrey Tan[MSFT] wrote:
>>> 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. [...]
>
> Btw., it's irritating that ZwSetInformationFile (FileRenameInformation)
> is "undocumented". FltSetInformationFile (FileRenameInformation) as
> well as the FILE_RENAME_OPERATION structure *are* documented and both
> refer to ZwSetInformationFile in terms of the FileRenameInformation
> class, see http://msdn2.microsoft.com/en-us/library/aa488684.aspx and
> http://msdn2.microsoft.com/en-us/library/ms791548.aspx(*).
>
> I don't quite understand why such a simple and basic operation should be
> treated as undocumented. It doesn't do anything hidden, dangerous, or
> mysterious.
>
>
> Corinna
>
>
> (*) The FILE_RENAME_OPERATION documentation isn't quite correct. It
> claims
>
> "A file cannot be renamed if it has any open handles, unless it is
> only open because of a [...] (oplock) [...]."
>
> A file or directory can be renamed regardless if it has an open handle
> or not, as long as the open handle is opened for sharing.
>
> --
> Corinna Vinschen
> Cygwin Project Co-Leader
> Red Hat


From: "Jeffrey Tan[MSFT]" on 30 Jan 2007 04:32
Hi Corinna ,

Sorry for letting you wait. Below is the further feedback, I got from the
File System developer:

"IoCallDriver passes down the driver stack. Assuming you have no filters
getting in the way and you're running on Ntfs, you'll end up in
NtfsSetRenameInfo.
Reading through this code now seems to suggest it's *supposed* to fail for
both files and directories.
//
// If this link has been deleted, then we don't allow this operation.
//
if (LcbLinkIsDeleted( Lcb )) {
NtfsStatusReturn (STATUS_ACCESS_DENIED);
}
Can you tell me what platform this is happening on?

A simple workaround might be to open the object *without* delete on close,
perform the rename, then mark your handle delete on close. It's an extra
round trip, but should solve this problem (assuming this is really the
problem.)"

Thanks

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

From: Corinna Vinschen on 30 Jan 2007 07:19
Hi Jeffrey,

Jeffrey Tan[MSFT] wrote:
> Regarding the reason of FILE_DELETE_ON_CLOSE fails for directory with
> FileRenameInformation, I want to know which account do you execute the
> code? Does it have delete child special permission on the directory?

The account doesn't matter. The behaviour is identical for a admin
account as well as a normal user account. As for the "delete child"
permission... in how far does that matter? The delete child perm
should only matter if we're removing a child object of a directory.
In my case we're talking about removing the directory itself.

> I am not familar with the internal work of ZwSetInformationFile with
> FileRenameInformation, so I tried to review the source code of ntoskrnl.exe
> ZwSetInformationFile API for FileRenameInformation. I find it did not do
> much magic, but pass the work to the file system driver with IoCallDriver
> calling. Sorry, I am not a DDK expert, so I will not dig more into to the
> File System driver level. Anyway, I will try to consult this issue with
> file system team internally for explanation. I will feedback any
> information here ASAP.

As you can see in my first reply to your posting, I have a solution for
this problem now. So it's just curiosity to learn why 'delete-on-close"
blocks the directory rename operation, while it's apparently no problem
to rename first and then to mark the directory for deletion.


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
From: Corinna Vinschen on 30 Jan 2007 07:22
Don Burn wrote:
> ZwSetInformationFile is documented for the DDK. The FltXXX calls are only
> for mini-filter drivers. The kernel has the rule that it will not remove a
> link which may be an anscestor path component of any open file. So it is
> unlikely you are going to get this to work.

Erm... sorry, I don't understand. I don't try to delete a directory
which has an open file, it's the directory itself which has been
opened.

My first reply to Jeffrey's posting shows the solution to this
problem. For files, just open for delete-on-close, rename, close.
For directories, open without delete-on-close, rename, mark for
deletion with FileDispostionInformation, close. It's strange that
it works differently for files and directories, but still, it works.


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
From: Corinna Vinschen on 30 Jan 2007 10:29
Hi Jeffrey,

Jeffrey Tan[MSFT] wrote:
> "IoCallDriver passes down the driver stack. Assuming you have no filters
> getting in the way and you're running on Ntfs, you'll end up in
> NtfsSetRenameInfo.
> Reading through this code now seems to suggest it's *supposed* to fail for
> both files and directories.
> //
> // If this link has been deleted, then we don't allow this operation.
> //
> if (LcbLinkIsDeleted( Lcb )) {
> NtfsStatusReturn (STATUS_ACCESS_DENIED);
> }
> Can you tell me what platform this is happening on?

Oh well, I developed and tested this on XP SP2 only, assuming the
behaviour would be consistent across different Windows versions. I took
the opportunity to test this now on all systems I could lay my hands on.

The following sequence

ZwOpen(FILE_DELETE_ON_CLOSE)
ZwSetInformationFile(FileRenameInformation)
ZwClose()

works on the following OSes like this:

- NT4 SP6: Succeeds on files and directories for all accounts.

- W2K SP4: Succeeds on files and directories for all accounts.

- XP SP2: Succeeds on files for all accounts.
Fails on directories for all account with ZwSetInformationFile
returning access denied error.

- 2K3 SP1: Succeeds on files and directories for all accounts.

Surprise, surprise:

- Vista: Succeeds on files and directories for non-restricted admin.
Succeeds on directories(!) for restricted admin and standard
user accounts.
Fails on files(!) for restricted admin and standard user
account with ZwSetInformationFile returning access denied
error.

All test files and directories were created with full permissions for
the testing account.

> A simple workaround might be to open the object *without* delete on close,
> perform the rename, then mark your handle delete on close.

Yep, that's what I do now, see my first reply in this thread. I'll have
to generalize this for files and directories, though.


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: RasEditPhoneBookEntry and Vista
Next: GetCurrentHwProfile determining dockability on Vista