folks,
i had a basic qn. when the file system is being queried for file size
using the irp_query_info or NtQueryInformationFile we get the size of
the file on the disc as wel as the eof which apparantly is the actual
number of bytes the file has.
however, i have seen instances where the EOF info is very very off, it
has a value of somewhere around 250GBs (in bytes of course) and this
seems to be a common occurance.
the actual file is very small, like a few kbs tops.
can someone help me as to why i see this? is this natural?
so if one wants to get the file size which one should they take, the
eof or the sizeondisk (which might be slightly bigger as it is based
on sector boundaries).
thanks
amit.
–
Sounds like you might be getting garbage. Have you looked at the sizes in
the FCB header?
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“amitr0” wrote in message news:xxxxx@ntfsd…
> folks,
>
> i had a basic qn. when the file system is being queried for file size
> using the irp_query_info or NtQueryInformationFile we get the size of
> the file on the disc as wel as the eof which apparantly is the actual
> number of bytes the file has.
>
> however, i have seen instances where the EOF info is very very off, it
> has a value of somewhere around 250GBs (in bytes of course) and this
> seems to be a common occurance.
>
> the actual file is very small, like a few kbs tops.
>
> can someone help me as to why i see this? is this natural?
>
> so if one wants to get the file size which one should they take, the
> eof or the sizeondisk (which might be slightly bigger as it is based
> on sector boundaries).
>
> thanks
>
> amit.
>
>
> –
>
> - amitr0
>
Scott,
thanks for trying to help. No, we couldn’t look at the FCB header as this
issue is happening at a customer site and is *very very rare*. When this
happens, the file size suddenly bloats up to 250Gigs. All he have are logs
to go on with right now.
thanks
amit
On Fri, Apr 16, 2010 at 1:12 AM, Scott Noone wrote:
> Sounds like you might be getting garbage. Have you looked at the sizes in
> the FCB header?
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> “amitr0” wrote in message news:xxxxx@ntfsd…
>
> folks,
>>
>> i had a basic qn. when the file system is being queried for file size
>> using the irp_query_info or NtQueryInformationFile we get the size of
>> the file on the disc as wel as the eof which apparantly is the actual
>> number of bytes the file has.
>>
>> however, i have seen instances where the EOF info is very very off, it
>> has a value of somewhere around 250GBs (in bytes of course) and this
>> seems to be a common occurance.
>>
>> the actual file is very small, like a few kbs tops.
>>
>> can someone help me as to why i see this? is this natural?
>>
>> so if one wants to get the file size which one should they take, the
>> eof or the sizeondisk (which might be slightly bigger as it is based
>> on sector boundaries).
>>
>> thanks
>>
>> amit.
>>
>>
>> –
>>
>> - amitr0
>>
>>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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
>
–
- amitr0
Are the other file sizes OK? The rule is that VDL <= EOF <= AllocationSize,
so if EOF is suddenly ginormous then there’s an issue.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“amitr0” wrote in message news:xxxxx@ntfsd…
Scott,
thanks for trying to help. No, we couldn’t look at the FCB header as this
issue is happening at a customer site and is very very rare. When this
happens, the file size suddenly bloats up to 250Gigs. All he have are logs
to go on with right now.
thanks
amit
On Fri, Apr 16, 2010 at 1:12 AM, Scott Noone wrote:
Sounds like you might be getting garbage. Have you looked at the sizes in
the FCB header?
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“amitr0” wrote in message news:xxxxx@ntfsd…
folks,
i had a basic qn. when the file system is being queried for file size
using the irp_query_info or NtQueryInformationFile we get the size of
the file on the disc as wel as the eof which apparantly is the actual
number of bytes the file has.
however, i have seen instances where the EOF info is very very off, it
has a value of somewhere around 250GBs (in bytes of course) and this
seems to be a common occurance.
the actual file is very small, like a few kbs tops.
can someone help me as to why i see this? is this natural?
so if one wants to get the file size which one should they take, the
eof or the sizeondisk (which might be slightly bigger as it is based
on sector boundaries).
thanks
amit.
–
- amitr0
—
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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
–
- amitr0
this is a very old legacy fs filter and has been in production for a
very long time. billions of io requests are processed (literally
billions) and then suddenly one file size would bloat up when a query
for it is made.
one observation is that it always happens with temp files, say you
open a word file and save it word renames a tmp file, those r the kind
of files which have shown problems.
is it possible that the query sent just at the time the file was
renamed to something else made the FO go away and returns garbage (the
value for eof is always the samem 256GB). since the query log is
generated at app level, and since i dont have access to the FCB etc
(clients production machine + impossible to repro inhouse) i am down
to reviewing code paths.
all customers are on ntfs and there is no indication of usage of
advanced fs features like sparse files, reparse points, txfs or
anything…it happens on all operating systems starting 2k3 and
above…
On 4/16/10, Scott Noone wrote:
> Are the other file sizes OK? The rule is that VDL <= EOF <= AllocationSize,
> so if EOF is suddenly ginormous then there’s an issue.
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “amitr0” wrote in message news:xxxxx@ntfsd…
> Scott,
>
> thanks for trying to help. No, we couldn’t look at the FCB header as this
> issue is happening at a customer site and is very very rare. When this
> happens, the file size suddenly bloats up to 250Gigs. All he have are logs
> to go on with right now.
>
>
> thanks
>
> amit
>
>
> On Fri, Apr 16, 2010 at 1:12 AM, Scott Noone wrote:
>
> Sounds like you might be getting garbage. Have you looked at the sizes in
> the FCB header?
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> “amitr0” wrote in message news:xxxxx@ntfsd…
>
>
> folks,
>
> i had a basic qn. when the file system is being queried for file size
> using the irp_query_info or NtQueryInformationFile we get the size of
> the file on the disc as wel as the eof which apparantly is the actual
> number of bytes the file has.
>
> however, i have seen instances where the EOF info is very very off, it
> has a value of somewhere around 250GBs (in bytes of course) and this
> seems to be a common occurance.
>
> the actual file is very small, like a few kbs tops.
>
> can someone help me as to why i see this? is this natural?
>
> so if one wants to get the file size which one should they take, the
> eof or the sizeondisk (which might be slightly bigger as it is based
> on sector boundaries).
>
> thanks
>
> amit.
>
>
> –
>
> - amitr0
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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
>
>
>
>
> –
>
> - amitr0
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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
>
–
- amitr0