Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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/
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! | ||
Internals & Software Drivers | 7 February 2022 | Live, Online |
Kernel Debugging | 21 March 2022 | Live, Online |
Developing Minifilters | 23 May 2022 | Live, Online |
Writing WDF Drivers | 12 September 2022 | Live, Online |
Comments
If you look at the bottom of the page you cited above you would see that ZwSetInformationFile allows you to change the file disposition. FltSetInformationFile is a wrapper for this for minifilters.
Thanks Don. Like with anything related to File systems, there are too many edge cases, and didn't want to break something which I didn't intend to by using the wrong flags.
On earlier OSes, you can only query FileModeInformation, but IIRC no FSes
process changing it.
Oh, is it? Doesnt say anywhere on the page though.
How? As far as I understand FILE_FLAG_DELETE_ON_CLOSE cannot be unset.. For example, this code tries to undo the flag but the file is still deleted:
If you write a minifilter you can remove the FILE_DELETE_ON_CLOSE flag in the pre-create callback then set FileDispositionInformation so it can be unset later...
Read this for more info about the details: https://fsfilters.blogspot.com/2011/10/file-deletion.html
On file systems that support it (e.g. NTFS in version 1607 and later), setting FileDispositionInformationEx with Flags == (FILE_DISPOSITION_DO_NOT_DELETE | FILE_DISPOSITION_ON_CLOSE) will clear delete-on-close state on that handle. Note that FILE_DISPOSITION_DO_NOT_DELETE is not an actual flag but rather for readability.
The combination (FILE_DISPOSITION_DELETE | FILE_DISPOSITION_ON_CLOSE) expresses setting delete-on-close state on that handle. We currently fail that combination with STATUS_NOT_SUPPORTED if the handle was not already in delete-on-close state, because we didn't want to introduce a new way to delete into the filter ecosystem unless there's a real need. However we succeed the combination if the handle is already in delete-on-close state (the trivial case), so that difference could be used to infer the state.
un setting delete on close seems like a dangerous feature unless the handle has delete access rights
@craigbarkhouse Thank you for the explanation, I didn't know that's possible