IRP_MJ_CREATE and STATUS_REPARSE

Hi All -

I’ve been under the (apparently mistaken) assumption that if you see a
IRP_MJ_CREATE, you will always (eventually) see an IRP_MJ_CLOSE.

However, it appears that when the IRP_MJ_CREATE returns a status of
STATUS_REPARSE, that there is never an IRP_MJ_CLEANUP sent down the stack,
but rather a new IRP_MJ_CREATE using the same FileObject.

Can anyone confirm that my observations are correct?

Are there any other cases where an IRP_MJ_CREATE might not have an
associated CLOSE, or where there could be two IRP_MJ_CREATEs on the same
FileObject without an IRP_MJ_CLOSE in between?

Thanks

Doug

I think you need to define ‘fileobject’. If you mean a value equal to another then it can happen. Use FileSpy and try various forms of create for file that exist and don’t exist. Consider trying files for which you do not have access due to permissions.

Also keep track of the FsContext which is a better indication of the file being accessed. You can have multiple FileObjects with the same FsContext. You must also check the status in the create completion to see if the file was opened and not maintain state on it if not. Reparse can be considered a form of failure in some cases. Read the FAQ, then read it again. Look at minispy and run it to see what is going on. You can also use the Sysinternals Process Monitor to do this but I like minispy since you can control the source and the data you want to see.

“Doug” wrote in message news:xxxxx@ntfsd…
Hi All -

I’ve been under the (apparently mistaken) assumption that if you see a IRP_MJ_CREATE, you will always (eventually) see an IRP_MJ_CLOSE.

However, it appears that when the IRP_MJ_CREATE returns a status of STATUS_REPARSE, that there is never an IRP_MJ_CLEANUP sent down the stack, but rather a new IRP_MJ_CREATE using the same FileObject.

Can anyone confirm that my observations are correct?

Are there any other cases where an IRP_MJ_CREATE might not have an associated CLOSE, or where there could be two IRP_MJ_CREATEs on the same FileObject without an IRP_MJ_CLOSE in between?

Thanks

Doug

I will read through the FAQ again - it’s been a while.

And I’m actually only looking at success statuses. For example, I just saw:

IRP_MJ_CREATE

IRP_MJ_CLOSE

IRP_MJ_QUERY_INFORMATION

IRP_MJ_READ

IRP_MJ_CLOSE

IRP_MJ_READ

all on the same PFILE_OBJECT! (I wasn’t logging IRP_MJ_CLEANUP so there
were probably some of those sprinkled in there). This was all on the
directory object \Device\HarddiskVolume1\Windows

Is my spying just broken, or is there some case where the above could
happen? (note that each operation was successful - no failures logged)

As far as PFILE_OBJECT vs FsContext, I’m really interested in each
‘transaction’ that takes place on a file (ie the user involved, the process
involved, etc) which from what I understand couldn’t be tracked via
FsContext because multiple processes could all open the same file and they’d
get the same FsContext value, right?

Thanks

Doug

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Saturday, April 25, 2009 6:35 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] IRP_MJ_CREATE and STATUS_REPARSE

I think you need to define ‘fileobject’. If you mean a value equal to
another then it can happen. Use FileSpy and try various forms of create for
file that exist and don’t exist. Consider trying files for which you do not
have access due to permissions.

Also keep track of the FsContext which is a better indication of the file
being accessed. You can have multiple FileObjects with the same FsContext.
You must also check the status in the create completion to see if the file
was opened and not maintain state on it if not. Reparse can be considered a
form of failure in some cases. Read the FAQ, then read it again. Look at
minispy and run it to see what is going on. You can also use the
Sysinternals Process Monitor to do this but I like minispy since you can
control the source and the data you want to see.

“Doug” wrote in message news:xxxxx@ntfsd…

Hi All -

I’ve been under the (apparently mistaken) assumption that if you see a
IRP_MJ_CREATE, you will always (eventually) see an IRP_MJ_CLOSE.

However, it appears that when the IRP_MJ_CREATE returns a status of
STATUS_REPARSE, that there is never an IRP_MJ_CLEANUP sent down the stack,
but rather a new IRP_MJ_CREATE using the same FileObject.

Can anyone confirm that my observations are correct?

Are there any other cases where an IRP_MJ_CREATE might not have an
associated CLOSE, or where there could be two IRP_MJ_CREATEs on the same
FileObject without an IRP_MJ_CLOSE in between?

Thanks

Doug

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

FILE_OBJECTs come from a lookaside list and as such they get reused. You’ll see the same FILE_OBJECT over and over again, you need to track its lifetime to figure out if it is being reused.

I think the easiest way to track the lifetime of a certain FILE_OBJECT is to attach a StreamHandle context to it. FilterManager will make sure it is torn down when the FILE_OBJECT is closed, so all you need to do is attach it when you find a FILE_OBJECT you care about.

Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.

>However, it appears that when the IRP_MJ_CREATE returns a status of STATUS_REPARSE, that

there is never an IRP_MJ_CLEANUP sent down the stack, but rather a new IRP_MJ_CREATE using
the same FileObject.

The file object is usually also not the same, but the new one.

Only the name is preserved in case of reparse.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

> However, it appears that when the IRP_MJ_CREATE returns a status of

STATUS_REPARSE, that there is never an IRP_MJ_CLEANUP sent
down the stack […snip]

Yup - As a first (and often approximation) filters should treat
STATUS_REPARSE in the same way as they treat a failure in post cleanup

And I’m actually only looking at success statuses. For example, I just
saw:

IRP_MJ_CREATE
IRP_MJ_CLOSE
IRP_MJ_QUERY_INFORMATION
IRP_MJ_READ
IRP_MJ_CLOSE
IRP_MJ_READ

Is my spying just broken

Possibly.

, or is there some case where the above could happen?

Yes. The documentation says (somewhere) that you should expect to see
operations (particularly closes) on file objects you never saw a creates
for. Consider a badly written filter which opens a file, but then decided
to send requests down the stack. Consider also StreamFileObjects…

As far as PFILE_OBJECT vs FsContext, I’m really interested in each
‘transaction’ that takes place on a file […snip]

I’d absolutely concur with Alex. Look at StreamHandleContexts - they pretty
much do exactly what you want, you don’t have to doubt whether your code has
bugs, you don’t have to worry about refcounting and if someone is hiding the
creates from you you can find this out and react appropriately.