Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/

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

Member Posts: 25

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.

• Member Posts: 25

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?

• Member - All Emails Posts: 1,173

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.

• Member - All Emails Posts: 374
edited December 2020

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)

• Member Posts: 25

@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?

• Member Posts: 25

@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.

• Member - All Emails Posts: 374
via Email
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.
• Member Posts: 25

@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.

• Member Posts: 25

@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.

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.

-scott
OSR

• Member Posts: 25

@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?

• Member - All Emails Posts: 1,173

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?

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.

• Member Posts: 25

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