From wdm.h (definition of IO_STACK_LOCATION):
//
// System service parameters for: NtReadFile
//
struct {
ULONG Length;
ULONG POINTER_ALIGNMENT Key;
LARGE_INTEGER ByteOffset;
} Read;
That doc section is full of it.
Filter manager’s callback data parameters is a copy of the IO_STACK_LOCATION
parameters, in the same format. If you are seeing a zero ByteOffset, that’s
exactly what was requested.
In my experience, you will rarely see FILE_USE_FILE_POINTER_POSITION unless
you create your own tests for it. I believe Win32 ReadFile either maintains
its own pointer, or gets it from the file object. Either way you end up
seeing explicit offsets.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, January 24, 2007 5:53 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Filter manager and cached operations
From the WDK documentation:
IrpSp->Parameters.Read.ByteOffset
Pointer to a LARGE_INTEGER variable that specifies the starting byte offset
within the file of the data to be read.
Under certain circumstances, this parameter might validly contain a NULL or
negative value. For example, if the file object was opened for synchronous
I/O, and one of the following conditions is true, this indicates that the
current file position should be used instead of an explicit file offset
value:
IrpSp->Parameters.Read.ByteOffset == NULL
IrpSp->Parameters.Read.ByteOffset.LowPart ==
IrpSp->FILE_USE_FILE_POINTER_POSITION
and IrpSp->Parameters.Read.ByteOffset.HighPart == -1.
So is the above incorrect or does the Filter Manager mess uo on the first
case and report zero.
My minifilter acts as a redirector in some cases, so in this case sends the
call to another system where it always reads the same blocks, even though
the open had the same options.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting http://www.windrvr.com
Remove StopSpam from the email to reply
“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
> Isn’t this the same as for a legacy filter? (It’s 1 am so I might
> need
> coffee)
>
> Don Burn wrote:
>
>> My typo, the file was opened with FILE_SYNCHRONOUS_IO_NONALERT. I
>> think the zero should be treated as use current file position, but
>> then what happens someone really wanted zero?
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> http://www.windrvr.com Remove StopSpam from the email to reply
>>
>> “Don Burn” wrote in message news:xxxxx@ntfsd…
>> > I’d like verification on something. Recently I had to change my
>> > filter
>> > so some read operations are caught before going through the cache
>> > manager. Trying a simple experiment from the command line of “type
>> > file”
>> > I do see a byte offset of zero for all the read requests. The file
>> > was
>> > opened with FILE_SEQUENTIAL_ONLY but the documentation on IRP_MJ_READ
>> > indicates that if the current position was to be used, that either a
>> > null
>> > or a “special value” should have been in the byte offset.
>> >
>> > Is this a filter manager bug since it does not use the “special
>> > value” (it obviously cannot be NULL) or a problem with
>> > documentation, or my brain damage?
>> >
>> >
>> > –
>> > Don Burn (MVP, Windows DDK)
>> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> > http://www.windrvr.com Remove StopSpam from the email to reply
>> >
>> >
>> >
>> >
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@alfasp.com To
>> unsubscribe send a blank email to xxxxx@lists.osr.com
>
> –
> King regards, Dejan
> http://www.alfasp.com
> File system audit, security and encryption kits.
>
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You should check the header files because the field isnt a