Open by ID and shadow device (part 2)

NTFSD
1

In create dispatch I’m handling “open by ID” request. Before calling
down FSD I’m opening this file via shadow device. For this I inject
FO->RelatedFO and FO->FileName into “shadow” path and ZwCreate that path
with open by ID option set. In the shadow device’s create dispatch if
“open by ID” flag is set I get RelatedFO from FileName, save it into
FO->RelatedFO, adjust FO->FileName and then call FSD below my shadow. In
debug I can see that just before I pass that request to FSD below shadow
the FO looks exactly like FO in the original create dispatch. While most
of the time this works sometimes I’m getting “special case” scenario
when shadow open fails (with invalid object name (C000000D) status)
while original open succeeds. Debugging reveals that shadow open fails
when RelatedFO name is “$Extend$Xxx” (where Xxx varies). Another thing
is that when shadow open fails (for the original create dispatch) actual
status that I see after shadow dev calls down its FSD is STATUS_REPARSE.
But in original create dispatch call to FSD returns STATUS_SUCCESS. What
else bothers me is that this is not that easy reproducible situation.
And I can spend hours before it occurs. Does this ring any bell for
anyone?

TIA,

Vladimir

2

… with some more observations.
In the shadow device, when I’m getting STATUS_REPARSE from FSD I can see
that FO->Vpb is initialized with VPB for the volume to which my shadow
dev is “attached”. Nothing else in FO seems to be initialized.
When I return from shadow’s create dispatch I see recursive entry into
my main create dispatch (in the same thread of the initial create
dispatch and before shadow’s ZwCreate is completed). What’s interesting
about that though is that FO points into a file which ID has been
initially requested BUT! This time FileName has correct (and normal:
“\mountpt\dirname”) path to that file (not an ID anymore), RelatedFO is
gone BUT STILL open by ID flag is set in create params. So, no wander
this request fails so fails my attempt to ZwCreate by ID through the
shadow dev. But best of all when I proceed with the initial IRP in the
main create dispatch I don’t see STATUS_REPARSE anymore. Create is
completed by FSD with STATUS_SUCCESS.

Still no bells? :wink:

Vladimir

-----Original Message-----
From: Vladimir Chtchetkine [mailto:xxxxx@borland.com]
Sent: Tuesday, March 02, 2004 5:30 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Open by ID and shadow device (part 2)

In create dispatch I’m handling “open by ID” request. Before calling
down FSD I’m opening this file via shadow device. For this I inject
FO->RelatedFO and FO->FileName into “shadow” path and ZwCreate that path
with open by ID option set. In the shadow device’s create dispatch if
“open by ID” flag is set I get RelatedFO from FileName, save it into
FO->RelatedFO, adjust FO->FileName and then call FSD below my shadow. In
debug I can see that just before I pass that request to FSD below shadow
the FO looks exactly like FO in the original create dispatch. While most
of the time this works sometimes I’m getting “special case” scenario
when shadow open fails (with invalid object name (C000000D) status)
while original open succeeds. Debugging reveals that shadow open fails
when RelatedFO name is “$Extend$Xxx” (where Xxx varies). Another thing
is that when shadow open fails (for the original create dispatch) actual
status that I see after shadow dev calls down its FSD is STATUS_REPARSE.
But in original create dispatch call to FSD returns STATUS_SUCCESS. What
else bothers me is that this is not that easy reproducible situation.
And I can spend hours before it occurs. Does this ring any bell for
anyone?

TIA,

Vladimir

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

… solved :slight_smile: I just had to “promote” FILE_OPEN_REPARSE_POINT flag in
create options to the shadow.

-----Original Message-----
From: Vladimir Chtchetkine [mailto:xxxxx@borland.com]
Sent: Wednesday, March 03, 2004 7:26 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Open by ID and shadow device (part 2)

… with some more observations.
In the shadow device, when I’m getting STATUS_REPARSE from FSD I can see
that FO->Vpb is initialized with VPB for the volume to which my shadow
dev is “attached”. Nothing else in FO seems to be initialized.
When I return from shadow’s create dispatch I see recursive entry into
my main create dispatch (in the same thread of the initial create
dispatch and before shadow’s ZwCreate is completed). What’s interesting
about that though is that FO points into a file which ID has been
initially requested BUT! This time FileName has correct (and normal:
“\mountpt\dirname”) path to that file (not an ID anymore), RelatedFO is
gone BUT STILL open by ID flag is set in create params. So, no wander
this request fails so fails my attempt to ZwCreate by ID through the
shadow dev. But best of all when I proceed with the initial IRP in the
main create dispatch I don’t see STATUS_REPARSE anymore. Create is
completed by FSD with STATUS_SUCCESS.

Still no bells? :wink:

Vladimir

-----Original Message-----
From: Vladimir Chtchetkine [mailto:xxxxx@borland.com]
Sent: Tuesday, March 02, 2004 5:30 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Open by ID and shadow device (part 2)

In create dispatch I’m handling “open by ID” request. Before calling
down FSD I’m opening this file via shadow device. For this I inject
FO->RelatedFO and FO->FileName into “shadow” path and ZwCreate that path
with open by ID option set. In the shadow device’s create dispatch if
“open by ID” flag is set I get RelatedFO from FileName, save it into
FO->RelatedFO, adjust FO->FileName and then call FSD below my shadow. In
debug I can see that just before I pass that request to FSD below shadow
the FO looks exactly like FO in the original create dispatch. While most
of the time this works sometimes I’m getting “special case” scenario
when shadow open fails (with invalid object name (C000000D) status)
while original open succeeds. Debugging reveals that shadow open fails
when RelatedFO name is “$Extend$Xxx” (where Xxx varies). Another thing
is that when shadow open fails (for the original create dispatch) actual
status that I see after shadow dev calls down its FSD is STATUS_REPARSE.
But in original create dispatch call to FSD returns STATUS_SUCCESS. What
else bothers me is that this is not that easy reproducible situation.
And I can spend hours before it occurs. Does this ring any bell for
anyone?

TIA,

Vladimir

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com