Behavior of rename directory

Hi, all

This is in fact not a question, but some note
after observation of filtering directory rename
operation. Maybe someone finds it interesting.

Let’s have two directories: E:\Normal and E:\Filtered
(Both are in the same volume)

Now I’m renaming directory E:\Normal\Subdir
into E:\Filtered, so the final subdirectory wil be
E:\Filtered\Subdir. The source directory contains a few files.
The target directory does not exist at the moment.

Well, now my filter finds that the rename cannot be done
for some reason, and completes the rename request
with STATUS_ACCESS_DENIED.

What a suprise! After returning that above status code,
I receive another rename request
E:\Normal\SubDir\File.ext ==> E:\Filtered\Subdir\File.ext.
(Obviously invoked by underlying test application

  • Total Commander)

The call succeeds, because the target directory exists,
obviously created by a previous IRP_MJ_CREATE
for the target directory.

Well, so does have any sense to return ACCESS_DENIED
in the first call of IRP_MJ_SET_INFORMATION ?

L.

Actually, Explorer will do something similar to this as well. Try
refusing ALL rename operations - Explorer will fall back to “copy and
delete” behavior to simulate rename. I suspect this is because it must
deal with cross-volume rename issues and that is how the shell
developers decided to do it.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Thursday, April 08, 2004 4:03 AM
To: ntfsd redirect
Subject: [ntfsd] Behavior of rename directory

Hi, all

This is in fact not a question, but some note
after observation of filtering directory rename
operation. Maybe someone finds it interesting.

Let’s have two directories: E:\Normal and E:\Filtered
(Both are in the same volume)

Now I’m renaming directory E:\Normal\Subdir
into E:\Filtered, so the final subdirectory wil be
E:\Filtered\Subdir. The source directory contains a few files.
The target directory does not exist at the moment.

Well, now my filter finds that the rename cannot be done
for some reason, and completes the rename request
with STATUS_ACCESS_DENIED.

What a suprise! After returning that above status code,
I receive another rename request
E:\Normal\SubDir\File.ext ==> E:\Filtered\Subdir\File.ext.
(Obviously invoked by underlying test application

  • Total Commander)

The call succeeds, because the target directory exists,
obviously created by a previous IRP_MJ_CREATE
for the target directory.

Well, so does have any sense to return ACCESS_DENIED
in the first call of IRP_MJ_SET_INFORMATION ?

L.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

> refusing ALL rename operations - Explorer will fall back to "copy and

delete" behavior to simulate rename.

For files only IIRC.

Even the directory tree deletion to Recycle Bin (which is rename) just fails if
this is a cross device move (it occurs this way with some ultra-smart kernel
software :slight_smile: ).

Worse so. Cross-device moves are caught and rejected in the IO manager itself,
and not delivered to FSFs.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> Worse so. Cross-device moves are caught and rejected in the IO manager
itself,

and not delivered to FSFs.

This is not a problem. FS filter can handle it as normal copy
(if the application “decides” to perform normal copy)

L.

I’ve observed Explorer move entire trees with the “copy and delete”
mechanism. As for where the error originates, the application can’t
tell if it comes from the I/O manager or a driver - it just looks like
an error to the application.

And, I would note that FAT still checks for the cross-volume rename
case:

//
// For a fully-qualified rename the target dcb is taken
from
// the target file object, which must be on the same vcb as
// the source.
//

PVCB TargetVcb;
PCCB TargetCcb;

if ((FatDecodeFileObject( TargetFileObject,
&TargetVcb,
&TargetDcb,
&TargetCcb ) != UserDirectoryOpen)
||
(TargetVcb != Vcb)) {

try_return( Status = STATUS_INVALID_PARAMETER );
}

I suspect this is a bigger issue on NTFS where we have volume mount
points - not all callers will be aware of them (e.g., a file server).
In our own file system work we also explicitly check to ensure the
target and source volumes of a rename are identical. Never wrong to
ensure the parameters from callers make sense!

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, April 08, 2004 9:00 AM
To: ntfsd redirect
Subject: Re: [ntfsd] Behavior of rename directory

refusing ALL rename operations - Explorer will fall back to “copy and
delete” behavior to simulate rename.

For files only IIRC.

Even the directory tree deletion to Recycle Bin (which is rename) just
fails if
this is a cross device move (it occurs this way with some ultra-smart
kernel
software :slight_smile: ).

Worse so. Cross-device moves are caught and rejected in the IO manager
itself,
and not delivered to FSFs.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com