All,
While experimenting with Minispy I see that SetFilePointer calls do not
result in IRP_MJ_SET_INFORMATION calls.
Example:
CreateFile (read/write)
SetFilePointer to x location inside File
ReadFile
This will not result in any IRP_MJ_SET_INFO, however, the consequent
ReadFile call will have the Offset x as read parameter.
My question is, is there a way in a mini filter where we can track the
SetFilePointer API as well?
Thanks
B
“Bedanto” wrote in message news:xxxxx@ntfsd…
>My question is, is there a way in a mini filter where we can track the
>SetFilePointer API as well?
At the native layer, this is an NtSetInformationFile for
FilePositionInformation. If the handle was opened for synchronous I/O, the
I/O Manager handles this internally without sending an IRP (ditto for the
NtQuery variant). As a filter driver you cannot see this.
Note that if you open the handle for asynchronous I/O you will see the
operation, the I/O Manager proceeds as normal in this case. So, you
shouldn’t expect to never see it, though it doesn’t have much meaning in
the async case.
-scott
OSR
“Bedanto” wrote in message news:xxxxx@ntfsd…
All,
While experimenting with Minispy I see that SetFilePointer calls do not
result in IRP_MJ_SET_INFORMATION calls.
Example:
CreateFile (read/write)
SetFilePointer to x location inside File
ReadFile
This will not result in any IRP_MJ_SET_INFO, however, the consequent
ReadFile call will have the Offset x as read parameter.
My question is, is there a way in a mini filter where we can track the
SetFilePointer API as well?
Thanks
B
Thanks for the clarification scott…
But this raises more questions…
What is the purpose of FilePositionInformation class then? Only for
Async IO? Or is it called in other cases also (I know of one, when one uses
SetFilePointer and follows it by SetEndOfFile)?
Assuming tht I am trying to virtualizing a file, that is, the reads of
the file would not hit the actual file system, but get satisfied in my mini
filter itself, should I be then setting the FileObject.CurrentByteOffset
field to IRP_READ’s Offset + Length? Experiments show that doing this sets
the file pointer correctly for the next ReadFile?
I studied the FASTFAT sources, and I in it I don’t see (perhaps I didn’t
look hard enough) the Read handler setting the CurrentByteOffset? This
makes me think that my #2 point above is incorrect. It would appreciate if
someone could help me with this confusion. The Write handler of FAT on the
other hand does set the parameter correctly.
If the NtSetInformationFile takes care of setting the File pointer for
Sync IO, does this mean it actually accesses teh FileObject (which is a
kernel object) and sets the CurrentByteOffset there? Or is there another
place this is set?
And finally the mother of all questions…if I want to virtualize a
file, and to make this simple, lets assume I use CreateFile to actual
create the file (makes it easier than creating the FileObject properly),
this newly created Zero byte file then needs to be handled by y mini
filter, so it seems that handling SetInfo/QueryInfo for properties wouldnt
be possible in all cases, since as scott said, some of these calls are
handled in user land itself. How can I then virtualize the file (yes i knw
I have other complex calls to worry about, but first i want to get the
easier ones right)…?
thanks
B
On Mon, May 6, 2013 at 10:05 PM, Scott Noone wrote:
> “Bedanto” wrote in message news:xxxxx@ntfsd…
>
> My question is, is there a way in a mini filter where we can track the
>> SetFilePointer API as well?
>>
>
> At the native layer, this is an NtSetInformationFile for
> FilePositionInformation. If the handle was opened for synchronous I/O, the
> I/O Manager handles this internally without sending an IRP (ditto for the
> NtQuery variant). As a filter driver you cannot see this.
>
> Note that if you open the handle for asynchronous I/O you will see the
> operation, the I/O Manager proceeds as normal in this case. So, you
> shouldn’t expect to never see it, though it doesn’t have much meaning in
> the async case.
>
> -scott
> OSR
>
> “Bedanto” wrote in message news:xxxxx@ntfsd…
>
> All,
>
> While experimenting with Minispy I see that SetFilePointer calls do not
> result in IRP_MJ_SET_INFORMATION calls.
>
> Example:
>
> CreateFile (read/write)
> SetFilePointer to x location inside File
> ReadFile
>
>
> This will not result in any IRP_MJ_SET_INFO, however, the consequent
> ReadFile call will have the Offset x as read parameter.
>
>
> My question is, is there a way in a mini filter where we can track the
> SetFilePointer API as well?
>
> Thanks
>
> B
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.**cfm?name=ListServerhttp:
></http:>
“Bedanto” wrote in message news:xxxxx@ntfsd…
>1. What is the purpose of FilePositionInformation class then?
>Only for Async IO?
Its purpose is to update the file position. As an implementation detail, the
I/O Manager just happens to perform the operation inline in the synchronous
I/O case.
>2. Assuming tht I am trying to virtualizing a file, that is, the
>reads of the file would not hit the actual file system, but get
>satisfied in my mini filter itself, should I be then setting the
>FileObject.CurrentByteOffset field to IRP_READ’s Offset + Length?
Yes, but only for synchronous, non-paging I/O.
>3. I studied the FASTFAT sources, and I in it I don’t see (perhaps
>I didn’t look hard enough) the Read handler setting the
>CurrentByteOffset?
You didn’t look hard enough 
The following sequence appears in read.c:
//
// If the file was opened for Synchronous IO, update the current
// file position.
//
if (SynchronousIo && !PagingIo) {
FileObject->CurrentByteOffset.LowPart =
StartingVbo + ActualBytesRead;
}
>4. If the NtSetInformationFile takes care of setting the File pointer
>for Sync IO, does this mean it actually accesses teh >FileObject
>(which is a kernel object) and sets the CurrentByteOffset there?
>Or is there another place this is set?
Yes. Though remember that the actual implementation of NtSetInformationFile
exists in kernel mode.
Hopefully the answers above clarify your #5 question.
-scott
OSR
Thanks for the clarification scott…
But this raises more questions…
1. What is the purpose of FilePositionInformation class then? Only for Async
IO? Or is it called in other cases also (I know of one, when one uses
SetFilePointer and follows it by SetEndOfFile)?
2. Assuming tht I am trying to virtualizing a file, that is, the reads of
the file would not hit the actual file system, but get satisfied in my mini
filter itself, should I be then setting the FileObject.CurrentByteOffset
field to IRP_READ’s Offset + Length? Experiments show that doing this sets
the file pointer correctly for the next ReadFile?
3. I studied the FASTFAT sources, and I in it I don’t see (perhaps I didn’t
look hard enough) the Read handler setting the CurrentByteOffset? This makes
me think that my #2 point above is incorrect. It would appreciate if someone
could help me with this confusion. The Write handler of FAT on the other
hand does set the parameter correctly.
4. If the NtSetInformationFile takes care of setting the File pointer for
Sync IO, does this mean it actually accesses teh FileObject (which is a
kernel object) and sets the CurrentByteOffset there? Or is there another
place this is set?
5. And finally the mother of all questions…if I want to virtualize a file,
and to make this simple, lets assume I use CreateFile to actual create the
file (makes it easier than creating the FileObject properly), this newly
created Zero byte file then needs to be handled by y mini filter, so it
seems that handling SetInfo/QueryInfo for properties wouldnt be possible in
all cases, since as scott said, some of these calls are handled in user land
itself. How can I then virtualize the file (yes i knw I have other complex
calls to worry about, but first i want to get the easier ones right)…?
thanks
B
On Mon, May 6, 2013 at 10:05 PM, Scott Noone wrote:
“Bedanto” wrote in message news:xxxxx@ntfsd…
My question is, is there a way in a mini filter where we can track the
SetFilePointer API as well?
At the native layer, this is an NtSetInformationFile for
FilePositionInformation. If the handle was opened for synchronous I/O, the
I/O Manager handles this internally without sending an IRP (ditto for the
NtQuery variant). As a filter driver you cannot see this.
Note that if you open the handle for asynchronous I/O you will see the
operation, the I/O Manager proceeds as normal in this case. So, you
shouldn’t expect to never see it, though it doesn’t have much meaning in
the async case.
-scott
OSR
“Bedanto” wrote in message news:xxxxx@ntfsd…
All,
While experimenting with Minispy I see that SetFilePointer calls do not
result in IRP_MJ_SET_INFORMATION calls.
Example:
CreateFile (read/write)
SetFilePointer to x location inside File
ReadFile
This will not result in any IRP_MJ_SET_INFO, however, the consequent
ReadFile call will have the Offset x as read parameter.
My question is, is there a way in a mini filter where we can track the
SetFilePointer API as well?
Thanks
B
—
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars 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
thanks scott. indeed it does answer all queries.
On Tue, May 7, 2013 at 1:01 AM, Scott Noone wrote:
> “Bedanto” wrote in message news:xxxxx@ntfsd…
>
> 1. What is the purpose of FilePositionInformation class then?
>> Only for Async IO?
>>
>
> Its purpose is to update the file position. As an implementation detail,
> the I/O Manager just happens to perform the operation inline in the
> synchronous I/O case.
>
>
> 2. Assuming tht I am trying to virtualizing a file, that is, the
>> reads of the file would not hit the actual file system, but get
>> satisfied in my mini filter itself, should I be then setting the
>> FileObject.CurrentByteOffset field to IRP_READ’s Offset + Length?
>>
>
> Yes, but only for synchronous, non-paging I/O.
>
>
> 3. I studied the FASTFAT sources, and I in it I don’t see (perhaps
>> I didn’t look hard enough) the Read handler setting the
>> CurrentByteOffset?
>>
>
> You didn’t look hard enough The following sequence appears in read.c:
>
> //
> // If the file was opened for Synchronous IO, update the current
> // file position.
> //
>
> if (SynchronousIo && !PagingIo) {
>
> FileObject->CurrentByteOffset.**LowPart =
> StartingVbo + ActualBytesRead;
>
> }
>
> 4. If the NtSetInformationFile takes care of setting the File pointer
>> for Sync IO, does this mean it actually accesses teh >FileObject
>> (which is a kernel object) and sets the CurrentByteOffset there?
>> Or is there another place this is set?
>>
>
> Yes. Though remember that the actual implementation of
> NtSetInformationFile exists in kernel mode.
>
> Hopefully the answers above clarify your #5 question.
>
> -scott
> OSR
>
>
> Thanks for the clarification scott…
>
> But this raises more questions…
>
> 1. What is the purpose of FilePositionInformation class then? Only for
> Async IO? Or is it called in other cases also (I know of one, when one uses
> SetFilePointer and follows it by SetEndOfFile)?
>
> 2. Assuming tht I am trying to virtualizing a file, that is, the reads of
> the file would not hit the actual file system, but get satisfied in my mini
> filter itself, should I be then setting the FileObject.CurrentByteOffset
> field to IRP_READ’s Offset + Length? Experiments show that doing this sets
> the file pointer correctly for the next ReadFile?
>
> 3. I studied the FASTFAT sources, and I in it I don’t see (perhaps I
> didn’t look hard enough) the Read handler setting the CurrentByteOffset?
> This makes me think that my #2 point above is incorrect. It would
> appreciate if someone could help me with this confusion. The Write handler
> of FAT on the other hand does set the parameter correctly.
>
> 4. If the NtSetInformationFile takes care of setting the File pointer for
> Sync IO, does this mean it actually accesses teh FileObject (which is a
> kernel object) and sets the CurrentByteOffset there? Or is there another
> place this is set?
>
> 5. And finally the mother of all questions…if I want to virtualize a
> file, and to make this simple, lets assume I use CreateFile to actual
> create the file (makes it easier than creating the FileObject properly),
> this newly created Zero byte file then needs to be handled by y mini
> filter, so it seems that handling SetInfo/QueryInfo for properties wouldnt
> be possible in all cases, since as scott said, some of these calls are
> handled in user land itself. How can I then virtualize the file (yes i knw
> I have other complex calls to worry about, but first i want to get the
> easier ones right)…?
>
>
> thanks
>
> B
>
>
>
> On Mon, May 6, 2013 at 10:05 PM, Scott Noone wrote:
> “Bedanto” wrote in message news:xxxxx@ntfsd…
>
> My question is, is there a way in a mini filter where we can track the
> SetFilePointer API as well?
>
> At the native layer, this is an NtSetInformationFile for
> FilePositionInformation. If the handle was opened for synchronous I/O, the
> I/O Manager handles this internally without sending an IRP (ditto for the
> NtQuery variant). As a filter driver you cannot see this.
>
> Note that if you open the handle for asynchronous I/O you will see the
> operation, the I/O Manager proceeds as normal in this case. So, you
> shouldn’t expect to never see it, though it doesn’t have much meaning in
> the async case.
>
> -scott
> OSR
>
> “Bedanto” wrote in message news:xxxxx@ntfsd…
>
> All,
>
> While experimenting with Minispy I see that SetFilePointer calls do not
> result in IRP_MJ_SET_INFORMATION calls.
>
> Example:
>
> CreateFile (read/write)
> SetFilePointer to x location inside File
> ReadFile
>
>
> This will not result in any IRP_MJ_SET_INFO, however, the consequent
> ReadFile call will have the Offset x as read parameter.
>
>
> My question is, is there a way in a mini filter where we can track the
> SetFilePointer API as well?
>
> Thanks
>
> B
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.**cfm?name=ListServerhttp:
>
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.**cfm?name=ListServerhttp:
></http:></http:>