Hi, guys, In the thread “Rename and STATUS_REPARSE” (http://www.osronline.com/showthread.cfm?link=223560) Alex Carp said he wrote a blog post named “Rename in File System Filters - part I”, I have already read it, but there is one thing i don’t understand :
Alex Carp said :“One feature that I feel would be very helpful here would be to add the source FILE_OBJECT into an ECP on the IRP_MJ_CREATE issued by IopOpenLinkOrRenameTarget, which would allow filters to detect what is the source file for the renam”.
My question is :
how do i get the SOURCE FILE_OBJECT when a precreate callback get called in IRP_MJ_CREATE with SL_OPEN_TARGET_DIRECTORY flag set? I looked FltObjects->FileObject->FileName but it is only contain rename target name. When my precreate callback get called where can i find any information about the rename source file ?
Alex Carp or any other guys that known about it could you please explain to me?
You can’t, the information simply isn’t there. You have to wait until the
actual rename happens to find out information about the source.
Also, note that SL_OPEN_TARGET_DIRECTORY opens are not strictly tied to
rename situations. IoCreateFileEx documents IO_OPEN_TARGET_DIRECTORY as an
option, which means that arbitrary third party components can use this
feature for their own purposes.
Hi, guys, In the thread “Rename and STATUS_REPARSE”
(http://www.osronline.com/showthread.cfm?link=223560) Alex Carp said he
wrote a blog post named “Rename in File System Filters - part I”, I have
already read it, but there is one thing i don’t understand :
Alex Carp said :“One feature that I feel would be very helpful here
would be to add the source FILE_OBJECT into an ECP on the IRP_MJ_CREATE
issued by IopOpenLinkOrRenameTarget, which would allow filters to detect
what is the source file for the renam”.
My question is :
how do i get the SOURCE FILE_OBJECT when a precreate callback get
called in IRP_MJ_CREATE with SL_OPEN_TARGET_DIRECTORY flag set? I looked
FltObjects->FileObject->FileName but it is only contain rename target name.
When my precreate callback get called where can i find any information about
the rename source file ?
Alex Carp or any other guys that known about it could you please explain
to me?
What Scott said… The only connection between the target and the source
exists further up the stack, in the code of whoever implements the rename…
Please note that it doesn’t have to be an OS component… Just like if you
wrote a perl script (for example) to open two files and copy from one to
the other, the connection between the two files exists only in your script
and the OS can’t even tell that you are just copying a file to another
file, all it sees are reads and writes.
My comment about how it would be helpful to have that ECP was meant to
address exactly this lack of information. I was thinking the OS could add
the ECP when it knows about a rename or hardlink creation operation (for
example in IopOpenLinkOrRenameTarget())… However, I don’t have any
expectation this will ever get implemented.
Thanks,
Alex.
On Fri, Apr 18, 2014 at 6:28 AM, Scott Noone wrote:
>
> > You can’t, the information simply isn’t there. You have to wait until the > actual rename happens to find out information about the source. > > Also, note that SL_OPEN_TARGET_DIRECTORY opens are not strictly tied to > rename situations. IoCreateFileEx documents IO_OPEN_TARGET_DIRECTORY as an > option, which means that arbitrary third party components can use this > feature for their own purposes. > > -scott > OSR > @OSRDrivers > > > wrote in message news:xxxxx@ntfsd… > > > Hi, guys, In the thread “Rename and STATUS_REPARSE” ( > http://www.osronline.com/showthread.cfm?link=223560) Alex Carp said he > wrote a blog post named “Rename in File System Filters - part I”, I have > already read it, but there is one thing i don’t understand : > > Alex Carp said :“One feature that I feel would be very helpful here > would be to add the source FILE_OBJECT into an ECP on the IRP_MJ_CREATE > issued by IopOpenLinkOrRenameTarget, which would allow filters to detect > what is the source file for the renam”. > > My question is : > how do i get the SOURCE FILE_OBJECT when a precreate callback get > called in IRP_MJ_CREATE with SL_OPEN_TARGET_DIRECTORY flag set? I looked > FltObjects->FileObject->FileName but it is only contain rename target > name. When my precreate callback get called where can i find any > information about the rename source file ? > > Alex Carp or any other guys that known about it could you please > explain to me? > > Thanks for helping > > > > — > NTFSD is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of debugging and file system seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
First many thanks to Scott and Alex for timely reply. Second, Is there really no solution to it? In other words, Does is mean that reparse the file operations on different volume like folder virtualization app are completely impossible ? Or there is better way to do folder virtualization? if there it is, please let me known
"User mode application rename directory ‘c:\windows\DirA’ to ‘c:\windows\DirB’,
The directory ‘c:\windows\DirA’ is redirected to ‘d:\cache\windows\DirB’, then
iomgr send a create irp with ‘SL_OPEN_TARGET_DIRECTORY’ on to open ‘c:\windows’.
I don’t know
which directory (‘c:\windows’ or ‘d:\cache\windows’) it really wants to open, so
I let it passthrough and fs open ‘c:\windows’.
Here Problem comes, the directory to be renamed and the target directory are not
in same volume, so there will be no rename irp. To user mode application, the
rename operation is failed, so it exits"
To handle this case in the virtualized scenario you need to handle the
rename processing internal to your filter driver. You handle this during
processing of the rename operation, performing the rename yourself. You
can always try to return the failure status STATUS_NOT_SAME_DEVICE which
will cause, in later OSs, the rename API to perform a copy/delete. But
for the example that was presented earlier, outside of the rename API,
this will fail. Again, in my experience, handling the rename processing
internal to your driver is the one fail-safe approach when dealing with
virtualized or redirected objects.
"User mode application rename directory ‘c:\windows\DirA’ to ‘c:\windows\DirB’,
The directory ‘c:\windows\DirA’ is redirected to ‘d:\cache\windows\DirB’, then
iomgr send a create irp with ‘SL_OPEN_TARGET_DIRECTORY’ on to open ‘c:\windows’.
I don’t know
which directory (‘c:\windows’ or ‘d:\cache\windows’) it really wants to open, so
I let it passthrough and fs open ‘c:\windows’.
Here Problem comes, the directory to be renamed and the target directory are not
in same volume, so there will be no rename irp. To user mode application, the
rename operation is failed, so it exits"
Hi Peter,you said:
“You handle this during processing of the rename operation, performing the rename yourself”
How do i handle it ?When and where?
In the situation i described above IoMgr even does not send an IRP_MJ_SET_INFORMATION down the stack. I couldn’t tell whether there is a rename operation or isn’t
I don’t think IOMgr would know the volumes are different until it
attempts to send down the rename request. Before then, as Alex and Scott
pointed out, the target directory open and the source file open are not
related. So maybe there is something else going on which is causing you
to not receive the rename request?
But once you get the rename request, if they truly are on different
volumes then you can implement a copy-delete for the rename. Otherwise
you will know the source and target names so perform the rename using
the FltSetFileInfo() API.
Hi Peter,you said:
“You handle this during processing of the rename operation, performing the rename yourself”
How do i handle it ?When and where?
In the situation i described above IoMgr even does not send an IRP_MJ_SET_INFORMATION down the stack. I couldn’t tell whether there is a rename operation or isn’t
On Fri, Apr 18, 2014 at 3:16 PM, Peter Scott wrote:
> > I don’t think IOMgr would know the volumes are different until it attempts > to send down the rename request. Before then, as Alex and Scott pointed > out, the target directory open and the source file open are not related. So > maybe there is something else going on which is causing you to not receive > the rename request? > > But once you get the rename request, if they truly are on different > volumes then you can implement a copy-delete for the rename. Otherwise you > will know the source and target names so perform the rename using the > FltSetFileInfo() API. > > Pete > > > On 4/18/2014 10:33 AM, xxxxx@gmail.com wrote: > >> Hi Peter,you said: >> “You handle this during processing of the rename operation, >> performing the rename yourself” >> >> How do i handle it ?When and where? >> >> In the situation i described above IoMgr even does not send an >> IRP_MJ_SET_INFORMATION down the stack. I couldn’t tell whether there is a >> rename operation or isn’t >> >> — >> NTFSD is sponsored by OSR >> >> OSR is hiring!! Info at http://www.osr.com/careers >> >> For our schedule of debugging and file system seminars visit: >> http://www.osr.com/seminars >> >> To unsubscribe, visit the List Server section of OSR Online at >> http://www.osronline.com/page.cfm?name=ListServer >> > > – > Kernel Drivers > Windows File System and Device Driver Consulting > www.KernelDrivers.com > 866.263.9295 > > > — > NTFSD is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of debugging and file system seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
Peter I’m afraid Alex is right. My user mode app will get result ACCESS_DENIED, when rename source and destination parameters of MoveFile function not in the same volume,and my filter driver that do implement some rename logic in IRP_MJ_SET_INFORMATION pre-callback doesn’t get called at all
Indeed, this is always the way that IopOpenLinkOrRenameTarget has worked. This is one reason why isolation filters end up being better solutions than reparse filters (since you don’t change the stack) in this situation.
Bottom line: if you want this to work right, you need both of these file objects (the original file object and the target file object) pointing to the same file system instance (which means either FO->Vpb->DeviceObject or FO->DeviceObject if the VPB is NULL and of course the I/O Manager is going to walk up the attached device chain in either case). If it doesn’t it returns STATS_NOT_SAME_DEVICE (as Pete suggested) which some APIs seem to convert into STATUS_ACCESS_DENIED (other APIs actually implement a copy/delete form of rename on top of this, but it’s not the OS that does that, it’s some Win32 magic…)
The challenge you have then is to make sure this happens in all the various possible cases AND that you handle it properly. As Pete suggested, in the end you’re going to end up figuring out where you need to send this.
Alex’s suggestion (including the original FO in an ECP) would be a reasonable solution to this exact problem - you’d know what volume the original file was on so you could return a Target FO against the same volume. No magic required. But in the interim, you’re stuck building a lot of infrastructure to handle this case.
Oh, don’t forget that this will also apply to hard links. You can’t create hard links across volumes, but you can do it on the same volume.
Oh,it seems very difficult to get this down with reparse filter , Tony
,could you please point me out how can i use isolation filters to make the
folder virtualization feasible, i have no idea what functions it could do
and how does it works
Thanks in advance
han kun
2014-04-20 8:31 GMT+08:00 Tony Mason :
>
> > Indeed, this is always the way that IopOpenLinkOrRenameTarget has worked. > This is one reason why isolation filters end up being better solutions > than reparse filters (since you don’t change the stack) in this situation. > > Bottom line: if you want this to work right, you need both of these file > objects (the original file object and the target file object) pointing to > the same file system instance (which means either FO->Vpb->DeviceObject or > FO->DeviceObject if the VPB is NULL and of course the I/O Manager is going > to walk up the attached device chain in either case). If it doesn’t it > returns STATS_NOT_SAME_DEVICE (as Pete suggested) which some APIs seem to > convert into STATUS_ACCESS_DENIED (other APIs actually implement a > copy/delete form of rename on top of this, but it’s not the OS that does > that, it’s some Win32 magic…) > > The challenge you have then is to make sure this happens in all the > various possible cases AND that you handle it properly. As Pete suggested, > in the end you’re going to end up figuring out where you need to send this. > > Alex’s suggestion (including the original FO in an ECP) would be a > reasonable solution to this exact problem - you’d know what volume the > original file was on so you could return a Target FO against the same > volume. No magic required. But in the interim, you’re stuck building a > lot of infrastructure to handle this case. > > Oh, don’t forget that this will also apply to hard links. You can’t > create hard links across volumes, but you can do it on the same volume. > > Tony > OSR > > > — > NTFSD is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of debugging and file system seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
Yes, more so, this is done before sending the IRP and thus cannot be customized in a driver.
“Alex Carp” wrote in message news:xxxxx@ntfsd… Well, IIRC the OS does compare the devices of the two FILE_OBJECTS (based on my post at http://fsfilters.blogspot.com/2011/06/rename-in-file-system-filters-part-ii.html, FltpOpenLinkOrRenameTarget() does this for fltmgr and I think the logic simply mirrors the logic in IopOpenLinkOrRenameTarget())…
Thanks, Alex.
On Fri, Apr 18, 2014 at 3:16 PM, Peter Scott wrote:
I don’t think IOMgr would know the volumes are different until it attempts to send down the rename request. Before then, as Alex and Scott pointed out, the target directory open and the source file open are not related. So maybe there is something else going on which is causing you to not receive the rename request?
But once you get the rename request, if they truly are on different volumes then you can implement a copy-delete for the rename. Otherwise you will know the source and target names so perform the rename using the FltSetFileInfo() API.
Hi Peter,you said: “You handle this during processing of the rename operation, performing the rename yourself”
How do i handle it ?When and where?
In the situation i described above IoMgr even does not send an IRP_MJ_SET_INFORMATION down the stack. I couldn’t tell whether there is a rename operation or isn’t