infos about Irp->UserIosb required

NTFSD
1

Hello,

I watched a behaviour of the Rdr, which seems to be new to Windows 2000,
and I couldn’t find any documentation, hints, etc. about it:

An Irp IRP_MJ_READ or IRP_MJ_WRITE with IRP_NOCACHE & IRP_PAGING_IO *NOT*
set comes along, imlpying read / write from / to the file cache. But
sometimes these data in Irp->UserBuffer are written through the cache to
the network, without any action of the lazy writer to be seen later (Irps
with IRP_NOCACHE & IRP_PAGING set).

Stepping deeper into the Irp structure, I’ve seen that in this case the
Irp->UserIosb contains specific information:

  • the Status and Pointer fields both are set with the value 0x00000103
    (STATUS_PENDING ??)
  • the Information field has a non zero value
    The Information field looks like to be used as a flag field, but there
    seems to be no straight forward regularity. Even worse, I’ve got the
    impression that this field specifies, whether the data are read from
    /written to the network directly or not.

Yet I have seen this only in Windows 2000 with the Rdr, and I assume that
it is unique to this Fs. Has anybody any additional ideas ? Or am I looking
in the wrong direction ?
By the way, you can see this when opening and saving documents with Word
(both 97 & 2000).

Glad for comments, ideas, hints etc.

Udo

2

> sometimes these data in Irp->UserBuffer are written through the cache to

the network, without any action of the lazy writer to be seen later (Irps
with IRP_NOCACHE & IRP_PAGING set).

Maybe oplock state prevents write-back caching on the client?

Max

3

Hmm, maybe. The UserIosb field my contain the desired FSCTL code, therefore
the desired oplock state. I’m digging deeper into it. But any suggestions,
how I can look up the currently granted oplock state of a file on a client
node ?
Udo