What's the point of IoReplaceFileObjectName()?

Hello,

If you are redirecting I/O in your filter you must create a new handle
to the target file, get it’s PFILE_OBJECT and replace
Iopb->TargetFileObject with the new one. Just replacing the file name
in Iopb->TargetFileObject is not enough because you still have the old
Vpb and FsContext and other stuff that’s specific to the original
file.

So what’s IoReplaceFileObjectName() good for? I can’t imagine any
scenario where IoReplaceFileObjectName() would do anything useful or
where it would not be necessary to create a new handle. Are there any
such scenario?

Thanks,


Aram Hăvărneanu

On 9/19/2010 3:56 PM, Aram Hăvărneanu wrote:

So what’s IoReplaceFileObjectName() good for? I can’t imagine any
scenario where IoReplaceFileObjectName() would do anything useful or
where it would not be necessary to create a new handle. Are there any
such scenario?

If you are performing reparse processing in pre-create then you need to
replace the FileObject->FileName with the new name, set
IoStatus.Information = IO_REPARSE and return STATUS_REPARSE. This causes
the IO Manager to reparse the name you put into the file object and
resend the request accordingly.

If you do this in a filter, particularly a mini-filter, then the memory
you allocate for the new name buffer will not be freed by you. Thus when
you attempt to unload the driver with verifier enabled, this allocation
will appear as a leak and cause a verifier exception. If you call the
above API, the memory allocation is not associated to your filter and
you can unload cleanly with causing a verifier exception.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

On Mon, Sep 20, 2010 at 1:16 AM, Peter Scott wrote:
> If you are performing reparse processing in pre-create then you need to
> replace the FileObject->FileName with the new name, set IoStatus.Information
> = IO_REPARSE and return STATUS_REPARSE. This causes the IO Manager to
> reparse the name you put into the file object and resend the request
> accordingly.

You are correct. I forgot about this scenario, which is ironic since I
started from the simrep sample which does exactly this…

> If you do this in a filter, particularly a mini-filter, then the memory you
> allocate for the new name buffer will not be freed by you. Thus when you
> attempt to unload the driver with verifier enabled, this allocation will
> appear as a leak and cause a verifier exception. If you call the above API,
> the memory allocation is not associated to your filter and you can unload
> cleanly with causing a verifier exception.

Yes, I understand the mechanism that causes such a function to be
needed if you wish to change the target file name, I did not
understand the need for changing the file name though.

I still think this function is not useful for anything but for when
returning STATUS_REPARSE, as in all other cases where you’d need to
change the file name (redirection) you’d need a new FILE_OBJECT,
correct?


Aram Hăvărneanu

Yeah, it was designed to work with STATUS_REPARSE and I’m not aware of any other scenario where it’s used.

Thanks,
Alex.