Open a file and FileObject(strange)

NTFSD
1

Hi All,

When I opened a file with two different apps, I found they opened the same FileObject.
It is really strange. Shouldn’t they get two different FileObjects?

I map “C:\dir1” to “C:\dir2”. It means if an app opens “\dir1\abc.txt”, it actually opens “\dir2\abc.txt”. When the file is opened in "\dir1", I attach a streamHandle context to it. If the file is opened in "\dir2", no streamHandle is attached.

But when I try to get streamHandle context from a fileObject opened from "\dir2", sometimes (not always), I can get a streamHandle.

So, how to identify whether a file is opened from "\dir1" or "\dir2"?
Thanks.

2

This is not possible. You either lost IRP_MJ_CLOSE inside your filter or the first open was not successful.

3

Hi Slava. Thanks for your reply.

>“You either lost IRP_MJ_CLOSE inside your filter or the first open was not successful.”

The first open was successful.

I did not filter the IRP_MJ_CLOSE. I thinks if a fileObject is closed, its attached StreamHandleContext should be deleted and freed automatically.

I used “notepad++.exe” to open a file and attached a streamHandleContext. and open the same file again with “sourceInsight.exe” and did not attached streamhandleContext. But in PreRead, I found I could get streamHandleContext when the current process is “sourceInsight.exe”. It’s really strange.

Have I missed something?
Thanks.

4

Yes.
Stream and file object are not equal. One stream can have multiple file objects. The system keeps file object to keep data cached. But this doesn’t mean that subsequent opens have the same File Object. They have the same stream.

5

Hi Slava, Thanks for your reply. I really appreciate it.

I agree with you that stream and fileObject are different. So I used streamHandle context.

I did another experiment, the result indicated that after a FileObject was cleanup but before closed, the FileObject could be opened again.

  1. when a file is opened by explorer.exe or notepad++.exe, a streamHandle context is attached to the FileObject.

  2. when the same file is opened again by wordpad.exe, do not attach streamHandle context to the new FileObject.

3.1 If I do NOT delete streamHandle contexts in IRP_MJ_CLEANUP, then sometimes in PreRead, when the current process is wordpad.exe, FltGetStreamHandleContext() returns success. As mentioned above, stream handle contexts are only attached for FileObjects opened by explorer.exe and notepad++.exe.

3.2 If I delete streamHandle contexts in IRP_MJ_CLEANUP, when the current process is wordpad.exe, FltGetStreamHandleContext() always fail.

I think the results indicate that:

  1. after cleanup, before close, the fileObject with a streamHandle context is opened again by wordpad.exe. so, even if no new streamHandle context is set, we can get the old one.

Tomorrow I am going to do more experiments.

Thanks.

6

Nobody here will give any reasonable explanation for FILE_OBJECT reuse without IRP_MJ_CLOSE as it doesn’t exist. The system doesn’t work this way.

If you believe you have found a bug report it to Microsoft.

7

I assume that at this stage you have dismissed paging IO from the loop?

What you describe would happen as a matter of course if you opened the file
on one path and established the cache with it, and then did cached
operations via the other path.

8

Thank you Rod.

>“I assume that at this stage you have dismissed paging IO from the loop?”

Sorry, what did you mean? I dealt with the Paging IO in READ and WRITE.

>“What you describe would happen as a matter of course if you opened the …”

Is there any way that can identify which path is a fileObject opened on, "\dir1" or "\dir2"?

Thanks.

9

>>“I assume that at this stage you have dismissed paging IO from the loop?”

Sorry, what did you mean? I dealt with the Paging IO in READ and WRITE.
Right - so in the READ path you may be handling (at top level) a read from
\dir1, but in the context of your CcCopyRead you’ll get a paging read form
\dir2. That’s all I meant.

10

Thanks Rod. I really appreciate your reply.