Hi,
We found an incompatibility issue between our SFO driver and App-V. The stream driver removes the FILE_OPEN_REPARSE_POINT flag in PreCreate and expects a possible STATUS_REPARSE in PostCreate to do some handling.
Internally, we resolve all cross-volume reparses handling STATUS_MOUNT_POINT_NOT_RESOLVED status too but seems we are doing a wrong behavior in some scenarios so my questions are:
a) If our call to FltCreateEx (to create the shadow FO) returns STATUS_MOUNT_POINT_NOT_RESOLVED, then we should retrieve the correct destination and return STATUS_REPARSE?
b) Also if tha call returns STATUS_SUCCESS, we “should” check if some reparse was fired internally and return the STATUS_REPARSE?
This implies drivers above us should do a similar handling so, at the end, I/O manager can do the correct redirection.
What I describe above, is the expected minifilter behavior?
Lots of questions…
Ignoring App-V for the moment. Are you in PreCreate processing and you’re
trying to open the file yourself with FltCreateFileEx? Or are you in some
other context (e.g. worker thread, PreIoctl, etc.) and trying to open the
file with FltCreateFileEx?
Usually there are two ways to handle this error. If you’re in PreCreate, you
can let the create operation proceed to the file system with the expectation
that you’ll see STATUS_REPARSE in PostCreate followed by a new open to the
actual target location. Alternatively you can retry the open with a NULL
instance parameter.
Why are you trying to interpret the reparse point yourself?
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
Hi,
We found an incompatibility issue between our SFO driver and App-V. The
stream driver removes the FILE_OPEN_REPARSE_POINT flag in PreCreate and
expects a possible STATUS_REPARSE in PostCreate to do some handling.
Internally, we resolve all cross-volume reparses handling
STATUS_MOUNT_POINT_NOT_RESOLVED status too but seems we are doing a wrong
behavior in some scenarios so my questions are:
a) If our call to FltCreateEx (to create the shadow FO) returns
STATUS_MOUNT_POINT_NOT_RESOLVED, then we should retrieve the correct
destination and return STATUS_REPARSE?
b) Also if tha call returns STATUS_SUCCESS, we “should” check if some
reparse was fired internally and return the STATUS_REPARSE?
This implies drivers above us should do a similar handling so, at the end,
I/O manager can do the correct redirection.
What I describe above, is the expected minifilter behavior?
Hi Scott,
I’m redirecting a folder to another volume so, in PreCreate I call FltCreateFileEx, create a “fake” FCB and then I redirect almost all I/O to that FO, taking special care about some operations… lessons I learned here 
Now back to the problem, let’s say I’m redirecting C:\test to D:\test, but, if inside D:\test, there is a subfolder D:\test\subfolder that points to C:\some-other-folder, it returns STATUS_MOUNT_POINT_NOT_RESOLVED but I manage to open the target and return success.
If D:\test\subfolder targets D:\some-other-folder, the FltCreateFileEx call succeedes because same volume.
But on both scenarios I think, I’m wrong and I should just get the destination and return STATUS_REPARSE.
Thanks,
Mauro.
OK, I understand your situation now.
We’ve done something similar in the past. What I ended up doing was what I
think you’re suggesting: reparsing the open over to “D:\test\subfolder” so
that it could be reparsed back over to “C:\some-other-folder”. That way you
don’t have to muck with the reparse point data, you just build a new name
with information you have readily available and let the I/O Manager do the
rest.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
Hi Scott,
I’m redirecting a folder to another volume so, in PreCreate I call
FltCreateFileEx, create a “fake” FCB and then I redirect almost all I/O to
that FO, taking special care about some operations… lessons I learned here
Now back to the problem, let’s say I’m redirecting C:\test to D:\test, but,
if inside D:\test, there is a subfolder D:\test\subfolder that points to
C:\some-other-folder, it returns STATUS_MOUNT_POINT_NOT_RESOLVED but I
manage to open the target and return success.
If D:\test\subfolder targets D:\some-other-folder, the FltCreateFileEx call
succeedes because same volume.
But on both scenarios I think, I’m wrong and I should just get the
destination and return STATUS_REPARSE.
Thanks,
Mauro.
Thanks Scott for your valuable information and for sharing the experience.
if this is cross volume nested link, as it seems, you can make use of ECPs
with FltCreateFileEx2 …using the following example on msdn,
https://msdn.microsoft.com/en-us/library/windows/hardware/hh971595(v=vs.85).aspx
This sample use it for only one link but calling it in a loop ,you can
handle nested links also.
But this will work for CrossVoulme link only …if same volume
FltCreateFileEx2 will pass.
What my concern is that you have to maintain the pointer to Instance along
with the FO , if you are going to call Fltxxxxx call to perform other IOs
on your shadow FO.
correct me if I am worng.
On Fri, Apr 28, 2017 at 12:20 AM, wrote:
> Thanks Scott for your valuable information and for sharing the experience.
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
–
मनीष आनंद सामरिया
Maneesh Anand.Samria</http:>
Hi Maneesh,
Yes we used that ECP on Win8+ and other method on Win7.
The doubt was basically what should we return to upper layer.
Thanks.
there are tow ways
- for IRP_MJ_Create …you return STATUS_REPARSE and the name of target (
you have to resolve it ), IO manager sends you IRP_MJ_Create again for the
target name redirect further IO from link FO to target FO.
- Implement the Shadow file object , open the target FO by resolveing the
name and return SUCCESS , IO manager will send all IOs on higher FO and you
have to implement them by Ftlxxx calls with proper Instance pointer and
make sure all IRPs are handled.
On Fri, Apr 28, 2017 at 10:31 PM, wrote:
> Hi Maneesh,
>
> Yes we used that ECP on Win8+ and other method on Win7.
>
> The doubt was basically what should we return to upper layer.
>
> Thanks.
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
–
मनीष आनंद सामरिया
Maneesh Anand.Samria</http:>
Hi Maneesh,
The problem is not about getting the target. The problem is what to return, STATUS_REPARSE or open the shadow FO and return sucess.
Regards,
Mauro.
It depends on your design. your choice.
handle redirection of IO yourself … or let IO manager do it.
this link may help you to design
http://fsfilters.blogspot.in/2012/02/problems-with-statusreparse-part-i.html
On Mon, May 1, 2017 at 9:01 PM, wrote:
> Hi Maneesh,
>
> The problem is not about getting the target. The problem is what to
> return, STATUS_REPARSE or open the shadow FO and return sucess.
>
> Regards,
> Mauro.
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
–
मनीष आनंद सामरिया
Maneesh Anand.Samria</http:>