STATUS_REPARSE and reentrance

NTFSD
1

Hello,

I want to redirect IRP_MJ_CREATE to other location on the same volume and I’d like to assign the old IRP to the new redirected IRP which will be sent by I/O Manager (since I’ll return STATUS_REPARSE). Is there a solid way how to identify these IRPs ?

I think, the new IRP can be received in the different thread – due to upper FS filters (so checking for the same ThreadID may be out of the question).

Is it possible to “sign” the old IRP (because the new one should be duplicated)? - if yes, what field in IRP should be the best?

I use this method so far: insertion the redirected path to the list and I check the path from IRP_MJ_CREATE handler - if there’s a match, IRP (I’m waiting for) points to the new location. The only problem is, there might be another IRP for the same location between returning STATUS_REPARSE and receiving new IRP – and I’d identify that IRP as a reparsed, but it wouldn’t be.

thanks,
Petr

2

You can’t touch an IRP after you have completed it. This means that signing
old IRP won’t work - it may disappear before the redirected IRP comes.

And since you don’t need to change volume replacing FileName in the
FileObject before passing the IRP down would be much easier solution.

Alexei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Petr Kurtin
Sent: Tuesday, September 26, 2006 1:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] STATUS_REPARSE and reentrance

Hello,

I want to redirect IRP_MJ_CREATE to other location on the same volume and
I’d like to assign the old IRP to the new redirected IRP which will be sent
by I/O Manager (since I’ll return STATUS_REPARSE). Is there a solid way how
to identify these IRPs ?

I think, the new IRP can be received in the different thread – due to
upper FS filters (so checking for the same ThreadID may be out of the
question).

Is it possible to “sign” the old IRP (because the new one should be
duplicated)? - if yes, what field in IRP should be the best?

I use this method so far: insertion the redirected path to the list and I
check the path from IRP_MJ_CREATE handler - if there’s a match, IRP (I’m
waiting for) points to the new location. The only problem is, there might be
another IRP for the same location between returning STATUS_REPARSE and
receiving new IRP – and I’d identify that IRP as a reparsed, but it wouldn’t
be.

thanks,
Petr

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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Yes, STATUS_REPARSE has a known issue - you cannot pass any info to the
reparsed CREATE path, except by encoding it in the very fancy filename :slight_smile:

Even the file object pointer is not OK - on STATUS_REPARSE, the OS destroys
this file object and creates another one for the reparsed attempt.

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

----- Original Message -----
From: “Petr Kurtin”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, September 27, 2006 12:58 AM
Subject: [ntfsd] STATUS_REPARSE and reentrance

Hello,

I want to redirect IRP_MJ_CREATE to other location on the same volume and
I’d like to assign the old IRP to the new redirected IRP which will be sent by
I/O Manager (since I’ll return STATUS_REPARSE). Is there a solid way how to
identify these IRPs ?

I think, the new IRP can be received in the different thread – due to
upper FS filters (so checking for the same ThreadID may be out of the
question).

Is it possible to “sign” the old IRP (because the new one should be
duplicated)? - if yes, what field in IRP should be the best?

I use this method so far: insertion the redirected path to the list and I
check the path from IRP_MJ_CREATE handler - if there’s a match, IRP (I’m
waiting for) points to the new location. The only problem is, there might be
another IRP for the same location between returning STATUS_REPARSE and
receiving new IRP – and I’d identify that IRP as a reparsed, but it wouldn’t
be.

thanks,
Petr

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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com