Thanks Rod for the plug! I do have some entries about querying MountMgr but
they don’t handle exactly this topic (this one covers the different volume
names and has a lot of links to other documentation:
http://fsfilters.blogspot.com/2012/03/volume-names.html; then there are
these two posts about how minifilters attach to volumes, but I’m afraid
they’re only tangentially related to the question:
http://fsfilters.blogspot.com/2011/03/how-file-system-filters-attach-to.html
and
http://fsfilters.blogspot.com/2011/03/how-file-system-filters-attach-to_17.html
).
Anyway, let me try to answer the questions. As to why the volume is mounted
using the RAW file system, it really depends on which OS you’re using. At
some point I think I understood most of the cases where the RAW filesystem
comes into play, but I’ve since forgotten and what I do these day is I just
exclude it from my filters (of course, I don’t do this by name, I just
query volume attributes and only attach to volumes that support the
particular attributes I’m interested in):
NTSTATUS status = STATUS_SUCCESS;
IO_STATUS_BLOCK ioStatus = {0};
FILE_FS_ATTRIBUTE_INFORMATION fsAttributes;
status = FltQueryVolumeInformation(FltObjects->Instance,
&ioStatus,
&fsAttributes,
sizeof(fsAttributes),
FileFsAttributeInformation);
//
// We only care about the FileSystemAttributes field so fail if
// we couldn’t get it. Otherwise force the status to SUCCESS.
//
if (ioStatus.Information <
RTL_SIZEOF_THROUGH_FIELD(FILE_FS_ATTRIBUTE_INFORMATION,
FileSystemAttributes)) {
NT_ASSERT(!NT_SUCCESS(status));
return status;
} else {
status = STATUS_SUCCESS;
}
//
// Only attach to file systems that support reparse points.
//
if (!FlagOn(fsAttributes.FileSystemAttributes,
FILE_SUPPORTS_REPARSE_POINTS)) {
return STATUS_FLT_DO_NOT_ATTACH;
}
So basically what I’m saying is ignore the mount as RAW, it’s interesting
to understand but not very relevant for filters.
Now, why do you see InstanceSetup callback on dismount ? Like Rod already
said, the act of creating or deleting volume mount points (D:\ or C:\test)
doesn’t really do any IO on the volume, but there are applications (like
Explorer) that might want to be notified about new drive letters showing up
(see IOCTL_MOUNTMGR_CHANGE_NOTIFY (
http://msdn.microsoft.com/en-us/library/windows/hardware/ff560451(v=vs.85).aspx))
and they might do things like figure out what icon to display next to the
drive letter in “My Computer” or something like that, that will require
some volume IO, which might mount the volume and at that point your
InstanceSetup will be called.
The thing I find puzzling in your setup is why you see an InstanceCallback
when you delete a drive letter, because that would imply that the volume
hasn’t been mounted until that time (if your filter attaches to a mounted
volume it will have its InstanceSetup callback called right away), but
again I wouldn’t really spend much time debugging it. Normally you wouldn’t
see any volume activity either when deleting or when adding drive letters
and mount points (meaning that if you actually care about that activity
then a file system minifilter might not be the right tool).
So I guess the real question is… why does all this matter ? What are you
trying to achieve ? If it’s just curiosity then you probably need to debug
it yourself (break in your InstanceSetup callback and look around the
system to figure out which IO triggered the mount - this applies to both
understanding why that RAW fs is mounted and to why you’re seeing a mount
when deleting the drive letter).
Thanks,
Alex.
On Mon, Jul 21, 2014 at 3:55 AM, Rod Widdowson
wrote:
> When I remove volume mount point(C:\test) then instancesetupcallback is not
>> called. why? Is it designed to be like that ?
>>
>
> I would suggest that you do some nature study with FileSpy. Then you’ll
> see what is going on.
>
> The file system and the device are there all along (look at it with
> FileTest and you’ll see that you can open \device\hardmumblefratz\dir\file,
> not matter what the disk management tool says) all that that tool is doing
> (except when you format and partition of course) is write symbolic links.
>
> I, for one, am surprised to see any activity in response to adding or
> removing dos devices - that should just be a symbolic link created up in IO
> manager’s private bit of that Namespace.
> For creating a mount point I would only expect to see some activity in
> “System Volume Information” plus of course the creation of the symbolic
> link.
>
> On the other hand the ways of umode-programmers are often hard to fathom.
>
> I’m sure that Alex has a blog entry about this, but I cannot see it on a
> brief search. If you haven’t looked there before take a couple of hours to
> go through http://fsfilters.blogspot.co.uk
>
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>