How to re-direct IRP_MJ_CREATE ? Two ways...................

NTFSD
1

I will re-direct IRP_MJ_CREATE.

I knows that a way is modifying the FileName field in IrpSp->FileObject and
then returning STATUS_REPARSE . This wayis OK!
But now, I use another way : I modify the FileName field in
IrpSp->FileObject , too, but I do not return STATUS_REPARSE . I continue to
pass this IRP modifyed by me, yet. By now, I never fail ! It seems that it
is also a feasible way.

I want to know if the second way is correct. If not, waht hidden trouble
there is ?

Thanks !

2

driver1 -> your_driver -> driver3 -> fs
it means, driver1 will work with different name (and lot of fs drivers cache
names in irp_mj_create)

if you return status_reparse, it will send a new request

“Leo” wrote in message news:xxxxx@ntfsd…
>I will re-direct IRP_MJ_CREATE.
>
> I knows that a way is modifying the FileName field in IrpSp->FileObject
> and then returning STATUS_REPARSE . This wayis OK!
> But now, I use another way : I modify the FileName field in
> IrpSp->FileObject , too, but I do not return STATUS_REPARSE . I continue
> to pass this IRP modifyed by me, yet. By now, I never fail ! It seems that
> it is also a feasible way.
>
> I want to know if the second way is correct. If not, waht hidden trouble
> there is ?
>
> Thanks !
>
>

3

Oh, I see.
Thank you !
“Petr Kurtin” wrote in message news:xxxxx@ntfsd…
> driver1 -> your_driver -> driver3 -> fs
> it means, driver1 will work with different name (and lot of fs drivers
> cache names in irp_mj_create)
>
> if you return status_reparse, it will send a new request
>
>
> “Leo” wrote in message news:xxxxx@ntfsd…
>>I will re-direct IRP_MJ_CREATE.
>>
>> I knows that a way is modifying the FileName field in IrpSp->FileObject
>> and then returning STATUS_REPARSE . This wayis OK!
>> But now, I use another way : I modify the FileName field in
>> IrpSp->FileObject , too, but I do not return STATUS_REPARSE . I continue
>> to pass this IRP modifyed by me, yet. By now, I never fail ! It seems
>> that it is also a feasible way.
>>
>> I want to know if the second way is correct. If not, waht hidden trouble
>> there is ?
>>
>> Thanks !
>>
>>
>
>

4

By the way, after returuning STATUS_REPARSE, it will send a new request.
Does it mean that the old FileObject would be free and a new FileObject
would be build ?

“Petr Kurtin” wrote in message news:xxxxx@ntfsd…
> driver1 -> your_driver -> driver3 -> fs
> it means, driver1 will work with different name (and lot of fs drivers
> cache names in irp_mj_create)
>
> if you return status_reparse, it will send a new request
>
>
> “Leo” wrote in message news:xxxxx@ntfsd…
>>I will re-direct IRP_MJ_CREATE.
>>
>> I knows that a way is modifying the FileName field in IrpSp->FileObject
>> and then returning STATUS_REPARSE . This wayis OK!
>> But now, I use another way : I modify the FileName field in
>> IrpSp->FileObject , too, but I do not return STATUS_REPARSE . I continue
>> to pass this IRP modifyed by me, yet. By now, I never fail ! It seems
>> that it is also a feasible way.
>>
>> I want to know if the second way is correct. If not, waht hidden trouble
>> there is ?
>>
>> Thanks !
>>
>>
>
>

5

> Does it mean that the old FileObject would be free and a new FileObject

would be build ?

Yes.

L.

6

Why shuold it not mean that the FileObject can be resued there and then and
why wold you even care?

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>> Does it mean that the old FileObject would be free and a new FileObject
>> would be build ?
>
> Yes.
>
> L.
>
>

7

> By the way, after returuning STATUS_REPARSE, it will send a new request.

Does it mean that the old FileObject would be free and a new FileObject
would be build ?

Yes, exactly so. You cannot pass any context to the second CREATE attempt from
reparse.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

8

Well, this (the second way) will not fail only if new file is located on
the same device stack to which your filter is attached. In other words,
if original file path is (for simplicity) c:\foo.c and the name you want
to redirect to is c:\foo\foo.c then you’re fine (assuming that this
will not create issues for filters above you). But if you want to
redirect create to d:\foo.c then you are screwed because this file is
accessible via completely different dev stack.

Vladimir Chtchetkine

Principal Engineer

Borland Software is the global leader in platform independent solutions
for Software Delivery Optimization, helping customers address the
constraints of modern day software development to maximize the business
value of their software.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Leo
Sent: Thursday, October 20, 2005 5:49 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] How to re-direct IRP_MJ_CREATE ? Two
ways…

I will re-direct IRP_MJ_CREATE.

I knows that a way is modifying the FileName field in IrpSp->FileObject
and then returning STATUS_REPARSE . This wayis OK!
But now, I use another way : I modify the FileName field in
IrpSp->FileObject , too, but I do not return STATUS_REPARSE . I continue

IrpSp->to
pass this IRP modifyed by me, yet. By now, I never fail ! It seems that
it is also a feasible way.

I want to know if the second way is correct. If not, waht hidden trouble
there is ?

Thanks !

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

9

Yes, Thanks!

Besides, I think that Petr Kurtin’s advice is very valuable, too.

“Vladimir Chtchetkine” wrote in message
news:xxxxx@ntfsd…
Well, this (the second way) will not fail only if new file is located on
the same device stack to which your filter is attached. In other words,
if original file path is (for simplicity) c:\foo.c and the name you want
to redirect to is c:\foo\foo.c then you’re fine (assuming that this
will not create issues for filters above you). But if you want to
redirect create to d:\foo.c then you are screwed because this file is
accessible via completely different dev stack.

Vladimir Chtchetkine

Principal Engineer

Borland Software is the global leader in platform independent solutions
for Software Delivery Optimization, helping customers address the
constraints of modern day software development to maximize the business
value of their software.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Leo
Sent: Thursday, October 20, 2005 5:49 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] How to re-direct IRP_MJ_CREATE ? Two
ways…

I will re-direct IRP_MJ_CREATE.

I knows that a way is modifying the FileName field in IrpSp->FileObject
and then returning STATUS_REPARSE . This wayis OK!
But now, I use another way : I modify the FileName field in
IrpSp->FileObject , too, but I do not return STATUS_REPARSE . I continue

IrpSp->to
pass this IRP modifyed by me, yet. By now, I never fail ! It seems that
it is also a feasible way.

I want to know if the second way is correct. If not, waht hidden trouble
there is ?

Thanks !

—
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

10

> But now, I use another way : I modify the FileName field in

IrpSp->FileObject , too, but I do not return STATUS_REPARSE . I continue
IrpSp->to pass this IRP modifyed by me, yet. By now, I never fail ! It
seems that
it is also a feasible way.

It is not clear if you send the IRP always to the same volume device or
you also may send it to another volume device.

If you send the IRP to another device, there is one hidden danger:
Another device may have different number of stack locations.
If the other one has greater number of stack locations than the
first one, you may get bugcheck NO_MORE_STACK_LOCATIONS,
because the number of stack locations for the IRP is determined by
the stack count for the target device when the IRP is created.

I am also afraid (but not sure) that your “undocumented” way will
cause the following IRPs (after successful create) will still be directed to
the original volume device object, which requires to redirect them too.

L.

11

Thanks !

“Vladimir Chtchetkine” wrote in message
news:xxxxx@ntfsd…
Well, this (the second way) will not fail only if new file is located on
the same device stack to which your filter is attached. In other words,
if original file path is (for simplicity) c:\foo.c and the name you want
to redirect to is c:\foo\foo.c then you’re fine (assuming that this
will not create issues for filters above you). But if you want to
redirect create to d:\foo.c then you are screwed because this file is
accessible via completely different dev stack.

Vladimir Chtchetkine

Principal Engineer

Borland Software is the global leader in platform independent solutions
for Software Delivery Optimization, helping customers address the
constraints of modern day software development to maximize the business
value of their software.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Leo
Sent: Thursday, October 20, 2005 5:49 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] How to re-direct IRP_MJ_CREATE ? Two
ways…

I will re-direct IRP_MJ_CREATE.

I knows that a way is modifying the FileName field in IrpSp->FileObject
and then returning STATUS_REPARSE . This wayis OK!
But now, I use another way : I modify the FileName field in
IrpSp->FileObject , too, but I do not return STATUS_REPARSE . I continue

IrpSp->to
pass this IRP modifyed by me, yet. By now, I never fail ! It seems that
it is also a feasible way.

I want to know if the second way is correct. If not, waht hidden trouble
there is ?

Thanks !

—
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

12

No, subsequent irps will always be sent to the correct device stack. The
stack is defined by FO’s Vpb->DeviceObject (or FO->DeviceObject if there
is no Vpb) and those fields are initialized by FSD in create dispatch.

Vladimir Chtchetkine

Principal Engineer

Borland Software is the global leader in platform independent solutions
for Software Delivery Optimization, helping customers address the
constraints of modern day software development to maximize the business
value of their software.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Sunday, October 23, 2005 8:33 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] How to re-direct IRP_MJ_CREATE ? Two
ways…

But now, I use another way : I modify the FileName field in
IrpSp->FileObject , too, but I do not return STATUS_REPARSE . I
IrpSp->continue to pass this IRP modifyed by me, yet. By now, I never
IrpSp->fail ! It
seems that
it is also a feasible way.

It is not clear if you send the IRP always to the same volume device or
you also may send it to another volume device.

If you send the IRP to another device, there is one hidden danger:
Another device may have different number of stack locations.
If the other one has greater number of stack locations than the first
one, you may get bugcheck NO_MORE_STACK_LOCATIONS, because the number of
stack locations for the IRP is determined by the stack count for the
target device when the IRP is created.

I am also afraid (but not sure) that your “undocumented” way will cause
the following IRPs (after successful create) will still be directed to
the original volume device object, which requires to redirect them too.

L.

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