Going back over working code to make it less hacky.
I have a situation where I want to mount a filesystem, that does not have a direct disk device under it.
The steps involved as I understand it something along the lines of:
- ???
- Receive (IRP_MJ_FILE_SYSTEM_CONTROL,IRP_MN_MOUNT_VOLUME)
- Attach my FSD
- Handle IRPs related to filesystem
Currently for “1” I call IoCreateDeviceSecure(FILE_DEVICE_DISK), + IoCreateSymbolicLink() and attempt to handle the
IRPs that come in for the “disk device”. Following example of winbtrfs, but there appears to be cracks. MountMgr is
never entirely happy with it nor the driveletter it gets. There are other possible issues as well, like that I can not get $Recycle.Bin to work.
I could spend more time debugging, trying to figure out if I reply incorrectly to some IRPs etc, but, I think
someone once recommended I use miniport to create the Volume, and attach my FSD. Could that work? Is that
a better way to go?
I have familiarised myself with a miniport example, and if I go through the steps:
- setup targetid+lun (0,0) and handle requests
- allow offset 0, size 512, to be written, and “read” back. Return zeros for everything else.
- possibly handle offset 0xe00, 0x10000 for efi and backup tables
- use DiskManager to Iinitialise Disk (writes offset 0, size 512)
- use DiskManager to create SimpleVolume (no filesystem) writes 0xe00.
- Receive (IRP_MJ_FILE_SYSTEM_CONTROL,IRP_MN_MOUNT_VOLUME)
It seems a little OverTheTop to use miniport for this, it creates a (fully working) \PHYSICALDRIVE after all, then having to
remember the partitiontable (or even just reply with a generated one) seems a little cumbersome. Maybe this direction wont lead to something
better and cleaner.
Is there an API framework I should be using to create the Volume to attach my FSD to? Presumably RAID managers, and RAM disks
have to do something similar, are there examples of that?
What path would the more seasoned developers take?