Rename and STATUS_REPARSE

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

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

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.

> 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

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.

> 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

As I said before, you won’t even get an IRP_MJ_SET_INFORMATION. There is nothing to complete.

Thanks,
Alex.

> 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

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.

> 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

Sorry, I haven’t yet looked at that particular sample, but perhaps someone that has can comment on this.

Thanks,
Alex.

“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

“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

> 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