I have filesystem minifilter and I get to PFLT_INSTANCE_SETUP_CALLBACK except volumes \Device\Harddiskvolume also physical disks, name such as \Device\Harddisk0\DR0. Do not understand why. Does it mean that I can attach to physical disk and be on the same layer as with PNP disk device filter driver? Will create/read/write requests to physical disk go through my minifilter callbacks? I don’t understand why I get objects at different layer to attach to (storage objects at filesys layer). And since I don’t want to attach to them is there any way how to detect these objects other than by name \Device\Harddisk?
What is the VolumeFilesystemType in this case? I suspect you will file
that this is the Raw Filesystem attempting to attach (and then detaching
IIRC).
wrote in message news:xxxxx@ntfsd…
Hello,
I have filesystem minifilter and I get to PFLT_INSTANCE_SETUP_CALLBACK
except volumes \Device\Harddiskvolume also physical disks, name such as
\Device\Harddisk0\DR0. Do not understand why. Does it mean that I can attach
to physical disk and be on the same layer as with PNP disk device filter
driver? Will create/read/write requests to physical disk go through my
minifilter callbacks? I don’t understand why I get objects at different
layer to attach to (storage objects at filesys layer). And since I don’t
want to attach to them is there any way how to detect these objects other
than by name \Device\Harddisk?
You are right, it is FLT_FSTYPE_RAW. So based on VolumeFilesystemType I can avoid attaching to physical disks. But still what is it good for to attach to raw disks in FS minifilter? If I want to filter disk access then I can write disk device upper filter driver.
Not raw disks, the raw file system - sublte (and probably not useful
distinction). My memory is that this is part of the mount protocol dance…
But still what is it good for to attach to raw disks in FS minifilter? If
I want to filter disk access
then I can write disk device upper filter driver.
Well, the raw file system is a file system and as such a filter can attach to it.
A volume filter might have other filters on top of it (for example a block level encryption filter like bitlocker) and as such you can’t really be sure that the data your volume filter sees is the same as the data the raw fs (or any FS) gets… Filter ordering for devices is not quite as well managed as for minifilters and as such this case can actually happen.
So what should I imagine behind RAW FS? Is it volume/partition? If I see read/write request with some offset, is it offset from beginning of the volume/partition? If I call FltGetVolumeName(FltObjects->Volume) in PFLT_INSTANCE_SETUP_CALLBACK I get name “\Device\Harddisk0\DR0”. So it looks like coming object doesn’t represent volume but physical disk, since “\Device\Harddisk0\DR0” is the name of FDO in storage stack.
> Not raw disks, the raw file system - sublte (and probably not useful
distinction). My memory is that this is part of the mount protocol dance…
Exactly.
In all usual cases (there are exceptions when AllowRawMount is not passed to IopParseDevice, but I don’t remember when they occur) - any open of the name like \.\c:, \?\Volume{guid} or volume PnP devinterface name - will cause a mount.
If none of the usual FSDs recognize the on-disk data - then RawFS is mounted.
RawFS is just a dummy stub which allows a) attach point for FS-level filters b) GetDiskFreeSpace(Ex) aka NtQueryVolumeInformationFile/FileFsSizeInformation on unformatted volumes without the sane FS.
So, if you’re filtering RawFS using FltMgr in this raw mode, you can see the IO which FORMAT does to lay down the new filesystem, as also all IO done by the apps which use raw partitions and their own data scheme on it (IIRC Oracle).
This is NOT block-level disk filtering. Well, to some extent this is block-level disk filtering, but it only filters block-level IO done by the user apps using CreateFile(\.\D:) or such. You will not see the block IO done by the FSD itself, and the real block device filter (unlike FltMgr in RAW mode) will see both in the same way.
> So what should I imagine behind RAW FS? Is it volume/partition?
It is a dummy FS shim which provides the “FS-ness” to volume/partition with the data not recognized by any real FS.
This “FS-ness” is really limited to a) GetDiskFreeSpace(Ex) b) attach point for FS-level filters c) pass-through (but filterable at FS level) reads/writes.
If I see read/write request with some offset, is it offset from beginning of the volume/partition?
Yes, same as for \.\d:. More so, Raw only supports this mode.
disk, since “\Device\Harddisk0\DR0” is the name of FDO in storage stack.
Yes.
This is to support the case the LUN is used without any partition table on it.