Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Sept/Oct 2019 Issue of The NT Insider available


Download PDF here: http://insider.osr.com/2019/ntinsider_2019_01.pdf

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

AllocationSize and EndOfFile advice

Jamey_KirbyJamey_Kirby Member - All Emails Posts: 439
edited August 16 in NTFSD

Looking for some advice. I have a filter that creates a zero byte file on a volume. The contents of the file is virtual. When a read or write request come through, I read and write the data somewhere else, not the physical file itself. When I respond to size queries, I can set the allocation size, and the end of file size. After doing some reading, I see that offline files will report zero as allocation size, but will report the actual file contents size for end of file. In my case, the file occupies no disk space, so I am inclined to return zero for the allocation size. When I do this everything looks good in the file manager. File properties show the size properly, and shows zero bytes on the disk. However, some tools see the file as zero bytes. HxD (hex editor) for example does not let me browse the file as it shows it as zero bytes. I guess HxD is reading the allocation size and not the EOF. If I set allocation size to the EOF, then the tools work properly. If I attach the virtual VHD file in disk manager, it works just fine with allocation size set to zero. So far, it only appears to be an anomaly with some tools.

I am asking should I continue to use zero to be more correct, or should I set them both to the EOF to ensure tools like HxD will work properly; correct for anomalies? What are your experiences?

Comments

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,183

    Applications should really only care about EOF. Anyone looking at AllocationSize is probably being a bit too cute and trying to optimize the case of a sparse file. Did you check ProcMon? It’s also possible the app is trying to get/read the physical extents of the file off the volume for some reason.

    So, what you’re doing should work, but there’s no telling what random applications will do...

    -scott
    OSR

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,073
    edited August 26

    I'd agree with @Scott_Noone_(OSR) but I'd add that if you start changing sizes (particularly eof, but I'd not definitely state that allocated is different) you have to make sure that MJ_QUERY_DIRECTORY is consistent. Many applications will get the length from the directory and treat it as the truth. IIRC there are even tests somewhere in the HCKs to test when the lengths in the DIRENT can change (and the associated oplocks fire) with respect to hard links.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE