重定向的弊端

[GoogleCodeExporter]

RE: name provider vs. status_reparse
Well, since we've already opened the can of worms :), there are a couple of
other things to consider when choosing between the two approaches.

I agree that reparse is a good solution for redirection. For virtualization
however it is a lot more complicated. However, if you're just looking to
implement some symlink-type solution then STATUS_REPARSE should be fine. 

While Razvan is certainly right when he says "you never know when another
filter decides to bypass your filter and sends the file object you own into
NTFS", this is a VERY serious architectural flaw in any filter and as far as
I know MS has stated that it will try to persuade developer of such filters
to fix their design (whatever that means... I imagine such filters will not
get the windows logo but there may be other things that I'm not aware of).
Also, although I have seen this behavior in the past, I've not run into it
in the past couple of years. As far as I know, the shadow file objects model
(i.e. taking ownership of the FILE_OBJECT) is the one MS recommends for
virtualization.

In terms of limitations of the STATUS_REPARSE method, here are a couple of
them off the top of my head:
1. it does not allow to virtualize file contents. For some projects this
isn't a problem, but for some it might be and it's a serious one. For
example, a deduplication solution that always reparses to the same file will
work as long as the file system is read-only, but if the requirement is that
someone can modify a de-duplicated file and that they receive their own copy
at that point, things can get tricky. 
2. if the virtualization is somewhat dynamic (so that \a\b will not always
point to \c\d but instead it can be changed to point to \e\f under some
circumstances) then you have the problem of out-of-sync handles. So some
handles for \a\b might point to \c\d on disk, while some will point to \e\f
and if some applications might use a file as a communication mechanism and
they might end up writing and reading from the wrong file. The same goes for
filters that use files for synchronization (I remember doing that in some
perl scripts...). 
3. clearly there is a layering problem, and two such virtualization filters
on the same machine will run into very interesting issues... Application
virtualization filters are pretty common these days...
4. there might be issues with namespace related stuff if you allow access to
a file through both names (if someone can open both \a\b and \c\d directly).
For example, implementing the name provider callbacks is going to be tricky
unless you can know which requests were reparsed and which were not, which
can be done in Vista and newer using ECPs, but is really hard to do for XP. 
5. if you reparse to a different device stack then any minifilter above
yours that calls FltCreateFile() with an instance and any legacy that calls
IoCreateFileEx() or IoCreateFileSpecifyDeviceObjectHint() with a device hint
(and all these are the recommended ways of doing it) will get a failure for
that create and might not function properly. 

Unfortunately, the shadow file object (SFO) model isn't as easy as
STATUS_REPARSE to get right, so hopefully MS will release a sample or OSR
will publish the source for the isolation filter they're writing about in
the NT Insider. There need to be more implementations of such filters before
the ecosystem adjusts to this (and filters that bypass other filters will
finally become too broken to be used at all). 

Ultimately though the decision is yours, my hope is that this will make you
make a more informed decision. 

Thanks,
Alex.

Original issue reported on code.google.com by m.azun...@gmail.com on 16 Nov 2012 at 9:04

[GoogleCodeExporter]

http://www.osronline.com/showThread.cfm?link=204494

Original comment by m.azun...@gmail.com on 16 Nov 2012 at 9:04