How to know Size of file ,?? is it IRP->UserBuffer

NTFSD
1

Dear all,

I am working on filespy program and need help from techies.

I have modifed a file and i need to know the size of the modified file.(
ie. c:\rohit.txt contents are deleted and the file is saved).
I need to put my routine in IRP_MJ_WRITE request. My progblem is that::

How can we know the size of the file from the IRP ?
Will Irp->UserBuffer help ?

Please suggest a way out.
Thank you
Regards,
Rohit

2

Rohit

To the best of my knowledge you cant get the size of the file from the
data you find in the Irp for IRP_MJ_WRITE. I assume by “size of the file”
you mean the end of file. So you need to ask the file system. You could
try a call to FsRtlGetFileSize() form ntifs.h If you want to do that I
advise you to take care because (a) this might be unsafe if the write is a
page write to a system page file [anyone?], (b) if you do this for every
write [module (a)] this can be expected to have quite a negative effect on
system performance.

Cheers
Lyndon

3

It is definitely unsafe to query for file size during paging I/O.

Lyndon J. Clarke wrote:

Rohit

To the best of my knowledge you cant get the size of the file from the
data you find in the Irp for IRP_MJ_WRITE. I assume by “size of the file”
you mean the end of file. So you need to ask the file system. You could
try a call to FsRtlGetFileSize() form ntifs.h If you want to do that I
advise you to take care because (a) this might be unsafe if the write is a
page write to a system page file [anyone?], (b) if you do this for every
write [module (a)] this can be expected to have quite a negative effect on
system performance.

Cheers
Lyndon

–
Nick Ryan (MVP for DDK)

4

Well now “paging I/O” seems to be a pretty broad term. There are page
reads and page writes - and other stuff - and there are system page files,
user mapped files, and plain old cached files. Is it definitely unsafe to
query for the file size in all of these cases?

5

Any IRP with the paging I/O flag set, because in this case filesystem
resources may have been pre-acquired by Mm or Cc, and the filesystem
will usually also try to acquire resources while processing the query,
which violates the locking heirarchy. The deeper architectural reason is
that changes to file size (increases at least, usually not decreases)
are not synchronized with paging I/O, so being able to query file size
is useless because it may change a millisecond later.

Lyndon J. Clarke wrote:

Well now “paging I/O” seems to be a pretty broad term. There are page
reads and page writes - and other stuff - and there are system page files,
user mapped files, and plain old cached files. Is it definitely unsafe to
query for the file size in all of these cases?

–
Nick Ryan (MVP for DDK)

6

When filter process request for paging IO some resources can be acquired
already. If filter attempts to query file size from file system, file system
internally acquire other resources. This may lead to wrong order in resource
acquisition thus potentially creating a deadlock.

Alexei.

“Lyndon J. Clarke” wrote in message
news:xxxxx@ntfsd…
>
> Well now “paging I/O” seems to be a pretty broad term. There are page
> reads and page writes - and other stuff - and there are system page files,
> user mapped files, and plain old cached files. Is it definitely unsafe to
> query for the file size in all of these cases?
>
>