\Device\HarddiskVolumeX\test.txt to drive path like C:\test.txt in mini-filter.

jay96612

In mini-filter driver, we get file path something like \Device\HarddiskVolumeX\test.txt so I need to convert this device path/name to drive path like c:\test.txt. In user mode, I have done using GetLogicalDriveStrings and then QueryDosDevice . So I wanted to know how can we do in mini-filter.

Any hint/idea will be much appreciated.
Thanks a lot.

jay96612

I have found a way to determine it using RtlVolumeDeviceToDosName and I have done it But since we are using the RtlVolumeDeviceToDosName in every pre-read callback so it will be much expensive. so how can we store it in the volume context of the pre-call back?

rod_widdowson

so how can we store it in the volume context of the pre-call back?

The same way you would store anything else? By why not do the work in instance setup?
 
Also if the user changes the DOS device names the caches information will become invalid. However IIRC the user is warned that badness may occurr when they change the DOS device names so you might consider this worth the risk.

Dejan_Maksimovic

Do not store it in the InstanceSetup unless your filter is not supposed to run on pre-win7 OSes, as that can deadlock.
Instead, have a flag in your volume context that is set to TRUE if the drive letter was found already.
Check that flag during IRP_MJ_CREATEs (all of them...). If it is FALSE, query the logical path, i.e.:

void MyDriver_ValidateDriveLetter(PMY_VOLUME_CONTEXT lpVolumeContext)
{
   if(lpVolumeContext->bDriveLetterFound)
      return;
   // query the volume name here
   // Set lpVolumeContext->bDriveLetterFound = TRUE if the call is successful
}

Note that there are cases where you cannot get the logical drive letter in InstanceSetup, as it might not be available yet. Also, the volume might not have a drive letter at all (on Windows 10, you are guaranteed at least one such partition, by default)

jay96612

@rod_widdowson yes, I did it in instance setup and it is working fine now.
I didn't understand these line:

Also if the user changes the DOS device names the cache's information will become invalid. However, IIRC the user is warned that badness may occur when they change the DOS device names so you might consider this worth the risk.

Could you please explain it more?

jay96612

@Dejan_Maksimovic Yes, my filter is not supposed to run on pre-win7 OSes so I can safely store it in the InstanceSetup. I will do it tomorrow and will notify you of any issues with that.

Thank you very much for the information you shared.

Dejan_Maksimovic

You still may need to do what I mentioned in IRP_MJ_CRETE.
The reason is that the DOS letter may not be available at the time
your InstanceSetup is called (possible if you are a boot driver) or
the drive might get assigned a letter later.

> @Dejan_Maksimovic Yes, my filter is not supposed to run on pre-win7 OSes so
> I can safely store it in the InstanceSetup. I will do it tomorrow and will
> notify you of any issues with that.

jay96612

@Dejan_Maksimovic okay I will check that flag in every IRP_MJ_CREATE and if it is false then I will query the logical path and set the flag true.

jay96612

@rod_widdowson yes, you are right. When I change the drive letter then the cache's information becomes invalid. so how to handle this case since volume context will not be updated.

Scott_Noone_(OSR)

We generally store the volume GUID name (FltGetVolumeGuidName) along with the instance and let something in user mode worry about converting it to a drive letter (or mount point) for display later (GetVolumePathNamesForVolumeNameW.

jay96612

@Scott_Noone_(OSR) I need to match the file path given from user mode and do it in kernel mode for blocking the access to that file. so If I use the device instance then on changing the drive letter manually, we get the path with the previous drive letter. so how can we get the new path using device instance or any other way?

rod_widdowson

A couple of questions:

• What do you do about hard links? If \foo\bar\jim is a barred but is hard linked to \foo\jim\bar do you allow access to the latter? Should you?
• What is your desired behavior? If e:\foo\bar\jim is blocked bur g:\foo\bar\jim not blocked, and someone changes "e:" to be "f:" and "g:" to be "e:" and then "f:" to "g:"

1. Is e:\foo\bar\jim still blocked?
2. What about g:\foo\bar\jim
3. And what about \??\device\HardDisk2\foo\bar\jim

Without understanding your requirements its hard to say but it seems to me that, as Scott says, inside the kernel you should stop worrying about the dos device symbolic link and concentrate on the things that are unique.

jay96612

okay, I got the idea. Thank you @Scott_Noone_(OSR) and @rod_widdowson