I'm working on a minifilter driver that "mounts" at a specified directory within an existing tree, e.g. c:\users\user\mymountpoint, and replaces everything from that point down with the contents of whatever "device" is mounted in much the same way that mounts under Linux work. The existing, underlying files/file system is essentially blocked/inaccessible while the minifilter is active.
This all works fine until I try to run an executable or open, say, a text file (using notepad). In the case of the executable, Windows gives me a popup telling me "This app can't run on your PC" without ever trying to read from the file (though it does try to read from file.exe:Zone.Identifier, which isn't present). If I try to execute from Git Bash, it does read the file but says that it can't be executed due to an "Exec format error".
In the case of the text file, I get "%1 is not a valid Win32 application", also with an attempt to open the Zone.Identifier metadata. However I can type file.txt at a DOS prompt and the contents display fine.
In both cases, using a Git Bash prompt, I can md5sum the files, and the contents match the same file on the drive itself.
Is there something I need to do to notify Windows that this portion of the file system isn't NTFS? Is there some attribute on the directory or file that I'm not returning to indicate something about the file(s)?
ETA: Per @MJZ's suggestion, I used Process Monitor to monitor activity when running notepad.exe c:\path\to\mymountpoint\file.txt.
Notepad does the following:
- Opens the containing directory
- Does a file listing for the file in question
- Closes the directory
- Opens the file
- Queries the volume information
- Queries "AllInformation" from the file
(Notepad does not supply enough space for the file name in this request. The driver fills in the available space and returns STATUS_BUFFER_OVERFLOW and the required size
- Closes the file
It's at this point that I get the "%1" error described above. If I change the return value of the AllInformation query to STATUS_BUFFER_TOO_SMALL, notepad returns an error that the file cannot be found.
Following @MJZ's suggestions, I ran ProcessMonitor against notepad opening a file both inside of my file system and outside. The difference was that in the working case, an IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION was being issued. No such IRP was being issued to my driver. It turns out that I wasn't setting/initializing the SectionObjectPointer of the file object when the file was opened/created.