Hi
I wrote a volume filter driver. I am handling IOCTL_MOUNTDEV_LINK_CREATED in
it. If the volume is mounted with driveletter I am first VOLUME GUID and
then Drive letter (\DosDevices\X:). But when the volume is mounted on a
directory (C:\mnt) I am getting only VOLUME GUID. DDK documentation shows
MOUNTDEV_NAME can hold (C:\mnt) also.
Am I missing something ?
Thanks in advance
James,
No you’re not missing anything. I’ve been there and banged my head
against the wall over it.
However, you need to step back a bit and consider the storage
hierarchy. When you mount a volume as a mount point inside another
volume this is a construct of the file system and not an attribute of
the volume. Since the file system (NTFS) sits above the volumes and
does all the relevant I/O mapping there is no reason for it to pass
the information down to the volume. In other words it is not an
essential piece of information that the volume needs to carry on working.
I admit that it would be very handy at times to know that the volume
has a mount point inside a file system hosted by another volume.
You can get the relevant mount point information only from above the
file system. I do it in a user mode DLL and merge it with low level
information from the volume filter driver to hand up to management
applications.
Mark.
At 11:43 AM 2/7/2008, James Thompson wrote:
Hi
I wrote a volume filter driver. I am handling
IOCTL_MOUNTDEV_LINK_CREATED in it. If the volume is mounted with
driveletter I am first VOLUME GUID and then Drive letter
(\DosDevices\X:). But when the volume is mounted on a directory
(C:\mnt) I am getting only VOLUME GUID. DDK documentation shows
MOUNTDEV_NAME can hold (C:\mnt) also.Am I missing something ?
Thanks in advance
- James
Thanks Mark
Is there any user mode API to get the list of all mount points for a volume
including the directories and drive letter ?
Does these directory mount points gets registered with Mount Manager ? If
yes when it gets registered ? How ?
Can IOCTL_MOUNTMGR_QUERY_POINTS work here to get all the mount points ?
On Feb 7, 2008 5:42 PM, Mark S. Edwards wrote:
> James,
>
> No you’re not missing anything. I’ve been there and banged my head
> against the wall over it.
>
> However, you need to step back a bit and consider the storage
> hierarchy. When you mount a volume as a mount point inside another
> volume this is a construct of the file system and not an attribute of
> the volume. Since the file system (NTFS) sits above the volumes and
> does all the relevant I/O mapping there is no reason for it to pass
> the information down to the volume. In other words it is not an
> essential piece of information that the volume needs to carry on working.
>
> I admit that it would be very handy at times to know that the volume
> has a mount point inside a file system hosted by another volume.
>
> You can get the relevant mount point information only from above the
> file system. I do it in a user mode DLL and merge it with low level
> information from the volume filter driver to hand up to management
> applications.
>
> Mark.
>
>
> At 11:43 AM 2/7/2008, James Thompson wrote:
> >Hi
> >
> >I wrote a volume filter driver. I am handling
> >IOCTL_MOUNTDEV_LINK_CREATED in it. If the volume is mounted with
> >driveletter I am first VOLUME GUID and then Drive letter
> >(\DosDevices\X:). But when the volume is mounted on a directory
> >(C:\mnt) I am getting only VOLUME GUID. DDK documentation shows
> >MOUNTDEV_NAME can hold (C:\mnt) also.
> >
> >Am I missing something ?
> >
> >Thanks in advance
> >
> >- James
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
At 03:57 PM 2/7/2008, James Thompson wrote:
Thanks Mark
Is there any user mode API to get the list of all mount points for a
volume including the directories and drive letter ?
GetVolumePathNamesForVolumeName() returns a list of path name strings.
Does these directory mount points gets registered with Mount Manager
? If yes when it gets registered ? How ?
Can IOCTL_MOUNTMGR_QUERY_POINTS work here to get all the mount points ?
No, these are file system constructs only. The kernel mount manager
is not told about them, there are no ioctls to catch or read. There
has to be some FSCTL that is called, but you’d only catch that as a
file system filter on top of NTFS. I’ve not explored that since it
would be a waste of time given I can do it in other ways.
There’s a specific semantic difference here that you’re getting hung
up on. “Mount” in terms of a volume surfacing and becoming active
within the storage stack is not the same thing as a “Mount” of one
file system inside a link in another. It just becomes a reparse
point in the host file system.
Because it’s easier, I tend to merge all the info in a user-mode
DLL. If you can work out the FSCTL to call you might work out a
method of resolving the information in kernel mode.
Mark.
On Feb 7, 2008 5:42 PM, Mark S. Edwards
<mailto:xxxxxxxxxx@muttsnuts.com> wrote:
>James,
>
>No you’re not missing anything. I’ve been there and banged my head
>against the wall over it.
>
>However, you need to step back a bit and consider the storage
>hierarchy. When you mount a volume as a mount point inside another
>volume this is a construct of the file system and not an attribute of
>the volume. Since the file system (NTFS) sits above the volumes and
>does all the relevant I/O mapping there is no reason for it to pass
>the information down to the volume. In other words it is not an
>essential piece of information that the volume needs to carry on working.
>
>I admit that it would be very handy at times to know that the volume
>has a mount point inside a file system hosted by another volume.
>
>You can get the relevant mount point information only from above the
>file system. I do it in a user mode DLL and merge it with low level
>information from the volume filter driver to hand up to management
>applications.
>
>Mark.
>
>
>At 11:43 AM 2/7/2008, James Thompson wrote:
> >Hi
> >
> >I wrote a volume filter driver. I am handling
> >IOCTL_MOUNTDEV_LINK_CREATED in it. If the volume is mounted with
> >driveletter I am first VOLUME GUID and then Drive letter
> >(\DosDevices\X:). But when the volume is mounted on a directory
> >(C:\mnt) I am getting only VOLUME GUID. DDK documentation shows
> >MOUNTDEV_NAME can hold (C:\mnt) also.
> >
> >Am I missing something ?
> >
> >Thanks in advance
> >
> >- James
>
>
>—
>NTDEV is sponsored by OSR
>
>For our schedule of WDF, WDM, debugging and other seminars visit:
>http:http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:http://www.osronline.com/page.cfm?name=ListServer
>
>
>— NTDEV is sponsored by OSR For our schedule of WDF, WDM,
>debugging and other 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</http:></http:></mailto:xxxxx>
> Is there any user mode API to get the list of all mount points for a volume
including the directories and drive letter ?
You must enumerate all mount points in the system and get the volume GUID for
each, then compare this GUID with your volume GUID.
This really works, I wrote such code once.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> GetVolumePathNamesForVolumeName() returns a list of path name strings.
Just plain absent on w2k even with all SPs.
No, these are file system constructs only. The kernel mount manager
is not told about them,
I think it reads some NTFS metadata streams where the lists of all such
“directories” are kept, this is necessary to be able to enumerate them.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
At 06:44 PM 2/7/2008, Maxim S. Shatskih wrote:
> GetVolumePathNamesForVolumeName() returns a list of path name strings.
Just plain absent on w2k even with all SPs.
I’m lucky, I don’t have to support W2K, just XP onwards 
So I
didn’t check on backwards compatibility.
> No, these are file system constructs only. The kernel mount manager
> is not told about them,I think it reads some NTFS metadata streams where the lists of all such
“directories” are kept, this is necessary to be able to enumerate them.
Yup, I know it’s in NTFS somewhere but my point to the OP was that
this sort of “mount” is part of a specific file system and thus no
knowledge of the operation is sent downwards by the f/s. It’s not a
generic feature of all file systems. Volume and F/S aren’t that far
apart in the stack and “mount” can mean too many things.
Mark.
Thanks Maxim and Mark
I need to support this for W2K also. Any suggestion ?
Enumerate all mount points and drive letters in the system.
For each of them, get the volume GUID.
Then compare this to the volume GUID in question.
This reproduces the function missing from w2k.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“James Thompson” wrote in message news:xxxxx@ntdev…
> Thanks Maxim and Mark
>
> I need to support this for W2K also. Any suggestion ?
>
Thanks Maxim. I tried this and it worked.
On Feb 10, 2008 2:08 AM, Maxim S. Shatskih wrote:
> Enumerate all mount points and drive letters in the system.
>
> For each of them, get the volume GUID.
>
> Then compare this to the volume GUID in question.
>
> This reproduces the function missing from w2k.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> “James Thompson” wrote in message news:xxxxx@ntdev
> …
> > Thanks Maxim and Mark
> >
> > I need to support this for W2K also. Any suggestion ?
> >
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>