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

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

More Info on Driver Writing and Debugging


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.

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

Comments

  • jay96612jay96612 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?

  • rod_widdowsonrod_widdowson 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.

  • Dejan_MaksimovicDejan_Maksimovic 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)

  • jay96612jay96612 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?

  • jay96612jay96612 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.

  • Dejan_MaksimovicDejan_Maksimovic 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.
  • jay96612jay96612 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.

  • jay96612jay96612 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.

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,379

    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

  • jay96612jay96612 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?

  • rod_widdowsonrod_widdowson 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?
    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.

  • jay96612jay96612 Member Posts: 25

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

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE