I know that I need to implement PreSetInfo callback to handle rename.
But my question is, this only work if I catch SetInformation before the I/O manager. How can I do that?? It seems that I need to AttachTo iomgr. How can I get the device of iomgr??
Hi,
it sounds like you don’t support all I/O operations behind MoveFileEx API.
This API consists of these three separated IOs:
IRP_MJ_CREATE(“\source.txt”) with DELETE flag
IRP_MJ_CREATE(“\target.txt”) with SL_OPEN_TARGET_DIRECTORY flag (!)
IRP_MJ_SET_INFORMATION(from “\source.txt” to “\target.txt”)
do you really reparse the 2nd IO on destionation’s folder? You can use
procmon to see which IO was reparsed incorrectly.
if you reparse on different volume, you should be ready to use the proper
Instance pointer (sometimes you need to read from source/destination place
and you can’t use the input fltObjects->Instance for these both operations).
Petr
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of dcg1981@163.com
Sent: Saturday, May 21, 2011 12:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] STATUS_REPARSE to another volume
Hello,
I’m writing a minifilter to redirect same files to the shadow files on
another volume.
I use STATUS_REPARSE when PreCreate. Everything works fine but ReplaceFile
API.
The use mode api ReplaceFile fails all the time when the file was redirected
to another volume.
I know that I need to implement PreSetInfo callback to handle rename.
But my question is, this only work if I catch SetInformation before the I/O
manager. How can I do that?? It seems that I need to AttachTo iomgr. How
can I get the device of iomgr??
I found it invoke the kernel api: ZwSetInformation, and the buf of the new file name is a full path.
For example, the original file is C:\A.txt, and the target file is C:\B.txt. ReplaceFile first open C:\A.txt, and the I/O is REPARSE to a shadow file in another VOLUME. And then ZwSetInformation is invoked. The buf of the new file is “C:\B.txt” ( always full path ). Notice that the two file are not in the same volume ( the original file was redirected to another volume ).
And it fails.
If I modify the buf, make it to be a relative path ( \B.txt ) , it will work fine!
But I have no chance to catch PreSetInformation if the buf is a full path. It seems that the iomgr return the error before I catch the IRP.
So, maybe I have to filt the iomgr in order to catch the PreSetInformation.
I found it invoke the kernel api: ZwSetInformation, and the buf of the new file name is a full path.
For example, the original file is C:\A.txt, and the target file is C:\B.txt. ReplaceFile first open C:\A.txt, and the I/O is REPARSE to a shadow file in another VOLUME. And then ZwSetInformation is invoked. The buf of the new file is “C:\B.txt” ( always full path ). Notice that the two file are not in the same volume ( the original file was redirected to another volume ).
And it fails.
If I modify the buf, make it to be a relative path ( \B.txt ) , it will work fine!
Of course, you can’t rename across volumes so you will need to update
this target name to one which is on the same volume as your re-targeted
file.
But I have no chance to catch PreSetInformation if the buf is a full path. It seems that the iomgr return the error before I catch the IRP.
Then you are doing something incorrect, you can intercept this on the
pre side and modify the content. But remember there are several cases
you need to deal with. Also, look at when the SL_OPEN_TARGET_DIRECTORY
flag is set on the open since this is where the underlying file system
builds the target name for the rename operation. For instance, if the
target of the rename is c:\foo\target.txt then an open will come in with
the above flag set on that path, indicating to the file system to open
the parent of the target in the path.
What’s the meaning of pre side? hook the api in USER MODE ?
Sorry, the pre-setfileinformation callback in filter manager. You need
to register a callback in your registration structure for the
IRP_MJ_SET_INFORMATION request.
And if no how can I catch the pre setinformation in this issues?
If you register a callback in the filter manager registration structure
for the above Irp, you will receive the pre-setfileinformation request.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting www.KernelDrivers.com
866.263.9295
> I use STATUS_REPARSE when PreCreate. Everything works fine but ReplaceFile API.
At least in pre-Vista Windows the move file path was doing a check for the volume to be the same, and this check was done before entering any drivers and before the drivers can influence it.
So, this is a very hard problem. Inject a hooker DLL to all processes using AppInit_DLLs is maybe the only solution.
The problem here is that NtSetInformationFile calls an internal function
that tries to open the parent directory of the target file and then it
verifies whether the file being renamed is on the same volume as that
directory and it will fail with STATUS_NOT_SAME_DEVICE if they’re not on the
same volume. So NtSetInformationFile will not even send the
IRP_MJ_SET_INFORMATION IRP down if they’re not on the same device. There
isn’t an easy workaround as far as I know.
That probably means he has not reparsed the directory?create to the shadow device. If he does that, NtSetInformationFile?should not see the difference…
?
Lijun
From: Alex Carp To: Windows File Systems Devs Interest List Sent: Thursday, June 2, 2011 3:02 PM Subject: RE: [ntfsd] STATUS_REPARSE to another volume
The problem here is that NtSetInformationFile calls an internal function that tries to open the parent directory of the target file and then it verifies whether the file being renamed is on the same volume as that directory and it will fail with STATUS_NOT_SAME_DEVICE if they’re not on the same volume. So NtSetInformationFile will not even send the IRP_MJ_SET_INFORMATION IRP down if they’re not on the same device. There isn’t an easy workaround as far as I know.
It depends. It could be the that the source file is on “source device” and
the target on the shadow device and it was reparsed as intended… Ultimately
the problem is that rename doesn’t work across volumes and as long as the
source is on a different volume from the target this will fail.
Thanks,
Alex.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lijun Wang
Sent: Thursday, June 02, 2011 1:15 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] STATUS_REPARSE to another volume
That probably means he has not reparsed the directory create to the shadow
device. If he does that, NtSetInformationFile should not see the
difference…
Lijun
From: Alex Carp To: Windows File Systems Devs Interest List Sent: Thursday, June 2, 2011 3:02 PM Subject: RE: [ntfsd] STATUS_REPARSE to another volume
The problem here is that NtSetInformationFile calls an internal function that tries to open the parent directory of the target file and then it verifies whether the file being renamed is on the same volume as that directory and it will fail with STATUS_NOT_SAME_DEVICE if they’re not on the same volume. So NtSetInformationFile will not even send the IRP_MJ_SET_INFORMATION IRP down if they’re not on the same device. There isn’t an easy workaround as far as I know.