As per the IFS kit documentation , a file cannot be renamed if it has any open handles.
I opened a file in Win32 application with share mode “FILE_SHARE_READ|FILE_SHARE_WRITE| FILE_SHARE_DELETE”. Now when I try to rename it from command line or from explorer, it gets renamed comfortably.
Is that an expected behavior?? Shouldn’t rename fail??
Sounds like a documentation bug. Opening a file for rename does not
require FILE_READ_DATA, FILE_WRITE_DATA or DELETE access and thus is
independent of normal file sharing checks.
My experience is that you can rename open files, so I wouldn’t consider
this unexpected behavior.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Hi
I have same experience as Tony. However WDK does say rename requires DELETE
access to the file. I’d just add that in my experience you can not rename a
directory while there is an open handle for a descendant thereof; unless you
use TxF features on Vista/Longhorn … and let’s not start on renaming
‘alternate’ data streams eh 
There does appear to be documentation error even in WDK 6000
ms-help://MS.WDK.v10.6000/IFSK_r/hh/IFSK_r/fileinformationstructures_d9a99263-5aec-400a-ab30-73949a81a4f6.xml.htm
Cheers
Lyndon
wrote in message news:xxxxx@ntfsd…
> As per the IFS kit documentation , a file cannot be renamed if it has any
> open handles.
>
> I opened a file in Win32 application with share mode
> “FILE_SHARE_READ|FILE_SHARE_WRITE| FILE_SHARE_DELETE”. Now when I try to
> rename it from command line or from explorer, it gets renamed comfortably.
>
> Is that an expected behavior?? Shouldn’t rename fail??
>
> Sounds like a documentation bug. Opening a file for rename does not
require FILE_READ_DATA, FILE_WRITE_DATA or DELETE access and thus is
independent of normal file sharing checks.
I am not sure about that. The MoveFileExW API opens the file being
moved for DELETE|SYNCHRONIZE access, I think renaming file requires
DELETE access.
I opened a file in Win32 application with share mode
“FILE_SHARE_READ|FILE_SHARE_WRITE| FILE_SHARE_DELETE”. Now when I
try to rename it from command line or from explorer, it gets renamed comfortably.
I assume you know the application is holding the file open
during rename operation. The this is expected behavior,
by opening with all share flags you say
“I allow everyone else to open the file for read, write and delete”.
L.
>Sounds like a documentation bug. Opening a file for rename does not
require FILE_READ_DATA, FILE_WRITE_DATA or DELETE access and thus is
independent of normal file sharing checks.
I think DELETE access is required. Renaming the file(from explorer or cmd) fails, if application doesn’t specify FILE_SHARE_DELETE flag.
I assume you know the application is holding the file open
during rename operation. The this is expected behavior,
by opening with all share flags you say
“I allow everyone else to open the file for read, write and delete”.
So this leads to the conclusion that file can be renamed even if it has a open handle( with DELETE share access). Can it be safely claimed that IFS kit documentation is not correct(or partially correct) in this case.
> I’d just add that in my experience you can not rename a
directory while there is an open handle for a descendant thereof
Mine too, also RDR/SRV has different constraints on when files may be
renamed (I seem to recall that you cannot rename files which have another
FileObject open for Write) and I have anecdotal evidence that in Vista there
are more secuirty level checks.
Finally you may need to be aware that if you do a
FltSetInformation/FileRenameInformation the filtermanager will issue a
FltCreateEx on your behalf which can cause interoperability issues
especuially with TxF on Vista.
and let’s not start on renaming ‘alternate’ data streams eh
Hey, why not? The obfuscation of the rename interface meets the
illogicality of the ADS interface head on 