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

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


AllocationSize and EndOfFile advice

Jamey_KirbyJamey_Kirby Member - All Emails Posts: 450
edited August 2019 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,302

    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,131
    edited August 2019

    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
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA