problem with notifications

NTFSD
1

Hi all,

I am implementing a virtual file system, that is, there is no associated h/w
device, and no VDOs or VPBs, only one CDO. From an NT service I define
drive letters, like P:, that points to the CDO by calling DefineDosDevice().
I am running on XP SP2.

The CDO is named “\Pifs”. The NT service defines drive letters like this:

DefineDosDevice( DDD_RAW, “P:”, “\Pifs\contextP;” )
DefineDosDevice( DDD_RAW, “Q:”, “\Pifs\contextQ;” )

When a win32 app opens “P:\test.txt”, my driver’s CREATE IRP sees
“\contextP;\test.txt”. And when a win32 app opens “Q:\test.txt”, my
driver’s CREATE IRP sees “\contextQ;\test.txt”. This seems good.

However, notifications don’t work. That is, if I have an Explorer open on
"P:", when I save to “P:\test.txt”, it does not get a file system
notification. I have the same results with fwatch (ReadDirectoryChangeW
sample app). Other than that, files can be opened, read, written to,
renamed, copied, closed. Directories can be enumerated.

I noticed that when Explorer browses to “P:", it sends a DIR_CRTL IRP with
IRP_MN_NOTIFY_CHANGE_DIRECTORY, and I call FsRtlNotifyFullChangeDirectory()
with the full directory name=”\contextP;", filter=0x17, watchtree=no. When
“P:\test.txt” is saved to, I call FsRtlNotifyFullReportChange() with the
full target name=“\contextP;\test.txt”, target name offset=11, filter=0x34,
action=3. Since the filter mask bits overlap and the path of the changed
file “descends” from the directory, I would expect
FsRtlNotifyFullReportChange() to complete the DIR_CTRL IRP.

However, if I define a drive letter in the NT service like this:

DefineDosDevice( DDD_RAW, “P:”, “\Pifs” )

notifications work. Create IRPs sees paths like “\test.txt”. In the
example above, FsRtlNotifyFullChangeDirectory() is called with the full
directory path=“", and FsRtlNotifyFullReportChange() with the full target
path=”\test.txt" and target name offset=1. But I don’t want to do this
because then I can’t have more than one drive letter.

Why would a symbolic link for a drive letter that points to the CDO itself
cause notifications to behave differently from a symbolic link that points
“into” the namespace of that CDO?

Thanks.

=================================================
Roger Tawa
http://tawacentral.net/
[One thing about paradigms: shift happens.]
[When you stop, you’re done.]

2

Maybe FsRtlNotifyFullChangeDirectory dislikes the semicolons in pathnames?

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

----- Original Message -----
From: “Roger Tawa”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, June 01, 2006 12:27 AM
Subject: [ntfsd] problem with notifications

> Hi all,
>
> I am implementing a virtual file system, that is, there is no associated h/w
> device, and no VDOs or VPBs, only one CDO. From an NT service I define
> drive letters, like P:, that points to the CDO by calling DefineDosDevice().
> I am running on XP SP2.
>
> The CDO is named “\Pifs”. The NT service defines drive letters like this:
>
> DefineDosDevice( DDD_RAW, “P:”, “\Pifs\contextP;” )
> DefineDosDevice( DDD_RAW, “Q:”, “\Pifs\contextQ;” )
>
> When a win32 app opens “P:\test.txt”, my driver’s CREATE IRP sees
> “\contextP;\test.txt”. And when a win32 app opens “Q:\test.txt”, my
> driver’s CREATE IRP sees “\contextQ;\test.txt”. This seems good.
>
> However, notifications don’t work. That is, if I have an Explorer open on
> “P:", when I save to “P:\test.txt”, it does not get a file system
> notification. I have the same results with fwatch (ReadDirectoryChangeW
> sample app). Other than that, files can be opened, read, written to,
> renamed, copied, closed. Directories can be enumerated.
>
> I noticed that when Explorer browses to “P:", it sends a DIR_CRTL IRP with
> IRP_MN_NOTIFY_CHANGE_DIRECTORY, and I call FsRtlNotifyFullChangeDirectory()
> with the full directory name=”\contextP;", filter=0x17, watchtree=no. When
> “P:\test.txt” is saved to, I call FsRtlNotifyFullReportChange() with the
> full target name=”\contextP;\test.txt", target name offset=11, filter=0x34,
> action=3. Since the filter mask bits overlap and the path of the changed
> file “descends” from the directory, I would expect
> FsRtlNotifyFullReportChange() to complete the DIR_CTRL IRP.
>
> However, if I define a drive letter in the NT service like this:
>
> DefineDosDevice( DDD_RAW, “P:”, “\Pifs” )
>
> notifications work. Create IRPs sees paths like “\test.txt”. In the
> example above, FsRtlNotifyFullChangeDirectory() is called with the full
> directory path=“", and FsRtlNotifyFullReportChange() with the full target
> path=”\test.txt" and target name offset=1. But I don’t want to do this
> because then I can’t have more than one drive letter.
>
> Why would a symbolic link for a drive letter that points to the CDO itself
> cause notifications to behave differently from a symbolic link that points
> “into” the namespace of that CDO?
>
> Thanks.
>
> =================================================
> Roger Tawa
> http://tawacentral.net/
> [One thing about paradigms: shift happens.]
> [When you stop, you’re done.]
>
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Thanks for the response and suggestion Maxim.

I don’t think the semi-colon is a problem, because I added that later
to help me parse out the context part. Initially, without the
semi-colon, when a win32 app opened the file “P:\test.txt” the CREATE
IRP would see “\contextP\test.txt”. This still did not send the
notification.

However, with some further debugging, I managed to narrow it down a
bit more. It seems that text files saved with Notepad cause this
problem. If I create a bitmap file with MS Paint and save it,
notifications seem to be sent correctly. If I create a new directory,
it works too. If I change file attributes, delete a file, it works.

But saving a text file in Notepad looses notifications. If I press F5
in Explorer, it seems to be correct again.

(BTW, when I say “looses notifications” and “seems to be correct
again”, what I mean is the display in Explorer does not change after
the save; the last modified time is unchanged, the file size is
unchanged. If I open the property page for the text file, though, I
see the *correct* information. When I press F5 in Explorer, the
display now shows the correct information.)

Note that all text is saved in the text document, I’m not loosing any
data. Need to keep looking into this one… I just ordered the
reprint of “Windows NT File System Internals” so I hope I get some
clues there.

So I can narrow down my original question further:

Why would a symbolic link for a drive letter that points to the CDO
itself cause Notepad notifications to behave differently from a
symbolic link that points “into” the namespace of that CDO?

=================================================
Roger Tawa
http://tawacentral.net/
[One thing about paradigms: shift happens.]
[When you stop, you’re done.]

4

> (BTW, when I say “looses notifications” and "seems to be correct

again", what I mean is the display in Explorer does not change after
the save; the last modified time is unchanged, the file size is
unchanged. If I open the property page for the text file, though, I
see the *correct* information. When I press F5 in Explorer, the
display now shows the correct information.)

In my experience, this is usual for NTFS. My own code which uses noncached
CreateFile to create the output files has the same issue.

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

5

Ah, that’s good to know Maxim, thanks.

Looking at the flags of the file object, I see that
FO_NO_INTERMEDIATE_BUFFERING is not specified, so I assume Notepad is
opening the file for cached i/o. However, Notepad does some funny
thing wrt memory mapping the file and such, so it probably is
different in that respect from MS Paint.

Also, the notifications do work when the symbolic link does not point
“into” the namespace of the CDO. So there is still something going on
that I don’t understand.

=================================================
Roger Tawa
http://tawacentral.net/
[One thing about paradigms: shift happens.]
[When you stop, you’re done.]