I put a raid into a new test setup and ran some of my code on it. I was looking to see why it suddenly wasnt so happy anymore with the path being passed into the driver.
Normally I use QueryDosDevice with a drive letter (“D:”) and I’ll get back “\Device\HarddiskVolume2” or maybe a different name of an odd path (much like I was getting from some vendors during plugfest interop, but either way, if I plugged the same name into FltGetVolumeFromName, it worked fine.
However in this case, QueryDosDevice returns “\Device\HarddiskDmVolumes\Xp32Dg0\Volume1”
And “Fltmc Volume” returns “\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1”
So when I use it in FltGetVolumeFromName it tells me no gold and fails. Is there a more reliable way (obviously this is XP32) to get the name from user mode or should I just do the attach/instancename/enumerate/lookup thing? And should I do it from kernel mode ‘Flt’ commands (thinking of VMs here) or will I get the same result from user mode Filter commands?
Fortunately, switching out a few lines to get the correct volume name was pretty easy. Just for reference (or until someone else suggests another way). I attached my filter to the drives with FilterAttach (since i needed to anyways) then create a routine that I pass the drive letter “R:” into it, which calls FilterVolumeInstanceFindFirst with InstanceFullInformation. Iterated the driver names, if it matched my driver’s name and instance name, I grabbed the VolumeNameBufferOffset and returned that back to my routine, as its the correct name that the filtermanager will let me use for getting that volume’s info.
I’m still interested to hear if anyone knows if getting the volume name is different from user mode or kernel mode regarding Terminal Server / sessions / virtual machines.
–Royal
Add dynamic disks to the mix to enable receiving different names even in the
kernel.
wrote in message news:xxxxx@ntfsd…
> Fortunately, switching out a few lines to get the correct volume name was
> pretty easy. Just for reference (or until someone else suggests another
> way). I attached my filter to the drives with FilterAttach (since i needed
> to anyways) then create a routine that I pass the drive letter “R:” into
> it, which calls FilterVolumeInstanceFindFirst with
> InstanceFullInformation. Iterated the driver names, if it matched my
> driver’s name and instance name, I grabbed the VolumeNameBufferOffset and
> returned that back to my routine, as its the correct name that the
> filtermanager will let me use for getting that volume’s info.
>
> I’m still interested to hear if anyone knows if getting the volume name is
> different from user mode or kernel mode regarding Terminal Server /
> sessions / virtual machines.
>
> --Royal
>
That I could see, but I suppose if you are getting the name from the filter manager to use in the filter manager, it should be correct since the mount/unmount would be the only real time the name would change. So keeping an eye on that as well, plus if it dismounts I would think your filter instance should have been knocked off that volume, so you would reattach, then requery again…
Then again, I dunno, is it possible to change a volume’s name without dismounting/remounting? Would sound a bit unstable to do.