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

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

Rename and STATUS_REPARSE

Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
I know that you have a virtualization filter implemented with
STATUS_REPARSE, cross-volume renames are very tricky to get right.
What's not clear to me if there's a way of making it work at all. I
guess there has to be a way, because that's how the MUP device works,
right?

Any thoughts appreciated.

Thanks,

--
Aram Hăvărneanu

Comments

  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    Aram Hăvărneanu wrote:
    > I know that you have a virtualization filter implemented with
    > STATUS_REPARSE, cross-volume renames are very tricky to get right.
    > What's not clear to me if there's a way of making it work at all. I
    > guess there has to be a way, because that's how the MUP device works,
    > right?

    s/you have/if you have/

    --
    Aram Hăvărneanu
  • Alex_CarpAlex_Carp Member Posts: 1,016
    Could you please explain what do you mean when you say that "that's how the MUP device works" ?

    The problem is that the IO manager is the one performing the check to see if it would be a cross-volume rename and if it thinks it would be then there won't be an IRP_MJ_SET_INFORMATION at all. Basically, if IopOpenLinkOrRenameTarget fails there is no rename sent to your filter. See my post here: http://fsfilters.blogspot.com/2011/06/rename-in-file-system-filters-part-i.html.

    In short, I would say there is no way to make this work in the general case. You might be able to make it work if you add some restrictions around your design, but since I don't know what your filter does I can't tell if that's even possible.

    Thanks,
    Alex.
  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    > See my post here:
    > http://fsfilters.blogspot.com/2011/06/rename-in-file-system-filters-part-i.html.
    >
    > In short, I would say there is no way to make this work in the
    > general case.

    That's what I think as well.

    > Could you please explain what do you mean when you say that
    > "that's how the MUP device works" ?

    I was under the impression that when a user accesses paths like
    \\a\b\c, the I/O manager sends the request to \Device\Mup like
    \Device\Mup\a\b\c, and the Mup device returns STATUS_REPARSE with a
    path to the real redirector, say \Device\MyRedirector1\b\c. Is this
    not the case? If this is indeed the case, how do renames work?

    Thanks,

    --
    Aram Hăvărneanu
  • Alex_CarpAlex_Carp Member Posts: 1,016
    Well, it would work for MUP if it is always reparsing to the same device. In other words, if your filter will always reparse a path on a volume to another device, then any rename on that path will actually work.
    So if you rename \Device\Mup\a\b\c\foo.txt to \Device\Mup\a\b\c\bar.txt then after reparses you actually have a FILE_OBJECT for \Device\MyRedirector1\b\c\foo.txt and you're trying to rename it to \Device\MyRedirector1\b\c\bar.txt, which is ok because they're both on the same device. However, if you were to rename \Device\Mup\a\b\c\foo.txt to \Device\Mup\baz\bar.txt, then you might end up a FILE_OBJECT as before (\Device\MyRedirector1\b\c\bar.txt) but the target folder would be \Device\MyRedirector2\, which is on a different device and it would fail...

    Does this make sense ?

    Thanks,
    Alex.
  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    > if your filter will always reparse a path on a volume to another
    > device, then any rename on that path will actually work.

    Unfortunately this is not the case, my filter does an union-mount[1].
    For example, it can overlay \\server\share\Users over
    C:\Users, serving the common names from the network.

    I understand the reasons why IRP_MJ_SET_INFORMATION will fail if I
    pass it down to the filesystem, but can't I complete
    IRP_MJ_SET_INFORMATION myself?

    [1] http://en.wikipedia.org/wiki/Union_mount

    --
    Aram Hăvărneanu
  • Alex_CarpAlex_Carp Member Posts: 1,016
    As I said before, you won't even get an IRP_MJ_SET_INFORMATION. There is nothing to complete.

    Thanks,
    Alex.
  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    > As I said before, you won't even get an
    > IRP_MJ_SET_INFORMATION. There is nothing to complete.

    Oh, yes, I see. Is there another way I could implement union mounts then?

    --
    Aram Hăvărneanu
  • Alex_CarpAlex_Carp Member Posts: 1,016
    In my experience it's not feasible to try to make files on a remote file system look like files on a local filesystem, the semantics are just too different. Still, i'd say that a layered file system is probably your best bet.

    Thanks,
    Alex.
  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    > In my experience it's not feasible to try to make files on a
    > remote file system look like files on a local filesystem, the
    > semantics are just too different. Still, i'd say that a layered
    > file system is probably your best bet.

    There's a new sample in the WDK 8 preview, NameChanger:
    http://code.msdn.microsoft.com/windowshardware/NameChanger-File-System-62ec4b1e

    It seems to do what SimRep does, only in a more complicated manner, I
    don't understand it yet. Does the method employed in NameChanger have
    the same limitations as the STATUS_REPARSE methid? Would this sample
    help me?

    Thanks,

    --
    Aram Hăvărneanu
  • Alex_CarpAlex_Carp Member Posts: 1,016
    Sorry, I haven't yet looked at that particular sample, but perhaps someone that has can comment on this.

    Thanks,
    Alex.
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,142
    "Aram Hăvărneanu" wrote in message news:xxxxx@ntfsd...
    >I was under the impression that when a user accesses paths like
    >\\a\b\c, the I/O manager sends the request to \Device\Mup like
    >\Device\Mup\a\b\c, and the Mup device returns STATUS_REPARSE with a
    >path to the real redirector, say \Device\MyRedirector1\b\c. Is this
    >not the case?

    Unrelated to the rest of the conversation, but just to be pedantic...

    You are correct in that this is the behavior of MUP for legacy redirectors
    (i.e. pre-Vista). In Vista and later there is FsRtlRegisterUncProviderEx, in
    which case the redirectors register unnamed device objects with MUP and the
    operations are distributed internally without going through reparse.

    -scott

    --
    Scott Noone
    Consulting Associate and Chief System Problem Analyst
    OSR Open Systems Resources, Inc.
    http://www.osronline.com

    -scott
    OSR

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,142
    "Aram Hăvărneanu" wrote in message news:xxxxx@ntfsd...
    >It seems to do what SimRep does, only in a more complicated manner, I
    >don't understand it yet. Does the method employed in NameChanger have
    >the same limitations as the STATUS_REPARSE methid? Would this sample
    >help me?

    I don't have any experience with this sample, though based on the
    description it sounds as if the directories grafted together have to be on
    the same volume:

    "The NameChanger minifilter grafts a directory from one part of a volume's
    namespace to another part using a mapping. "

    This is much simpler than trying to graft multiple different volumes.

    -scott

    --
    Scott Noone
    Consulting Associate and Chief System Problem Analyst
    OSR Open Systems Resources, Inc.
    http://www.osronline.com

    -scott
    OSR

  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    > This is much simpler than trying to graft multiple different volumes.

    Thanks both for your input. I planned to cache the network data on
    local disk, for obvious reasons, so I might just solely use the cache
    for this. Of course, before returning STATUS_REPARSE I have to make
    sure the data has already been cached, so I have to do I/O in
    pre-Create. This complicates things.

    --
    Aram Hăvărneanu
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