Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

What's the point of IoReplaceFileObjectName()?

Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
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

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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
  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    On Mon, Sep 20, 2010 at 1:16 AM, Peter Scott <xxxxx@kerneldrivers.com> 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
  • Alex_CarpAlex_Carp Member Posts: 1,016
    Yeah, it was designed to work with STATUS_REPARSE and I'm not aware of any other scenario where it's used.

    Thanks,
    Alex.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA