For example, network drive mapping is user-specific.
L.
Thank you,
You are right. I think I didn’t specified clearly my question. What I
really want to know, if we can obtain user-specific mappings for local
drives? For example, it is possible, to have let’s say three different 5
GB local partitions (on the same local disk), and map one of those for
three different users, under the same drive letter?
(Btw. I just found an interesting scenario just playing with Disk
Management under Vista. Initially, for UserA I had a network drive N:
mapped to a shared folder on the net, then I switched to UserB, and
using Disk Management I *could* change the drive mapping for a local
driver (previously T:) to N:, because for UserB the mapping N: was not
used (it is network, so per-user). Now, after this I switched back to
UserA, and surprise, the previously known T: just disappeared, and it
was still using N: for the network mapping. However, when I was checking
from Disk Management, under UserA, it was saying, that the local volume
that was previously T: was now N:, but, when I tried to open it, it just
opened the network mapped driver. It seems to me that this is clearly an
inconsistency, at least from the part of Disk Management (how can a MS
admin tool say ‘yo, we have a volume N: here’, then, when I just open
that volume, using the very same tool, show up to me a different volume?).
thank you very much,
Sandor LUKACS
Virus Analyst, SOFTWIN
Ladislav Zezula wrote:
For example, network drive mapping is user-specific.
L.
> drives? For example, it is possible, to have let’s say three different 5
GB local partitions (on the same local disk), and map one of those for
three different users, under the same drive letter?
Assuming network drive mapping is nothing else than a user-specific
symbolic link, then you can create the same link for local drives
as well.
I don’t know if an application uses it, but once it
is in the OS, your driver must count on it.
L.
> issues. The common case is fast user switching where a given volume
under one user is mapped to c: whereas under the second user it is
mapped to d:.
Only SMB “volumes” are per-user, harddisk volumes are not.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Ok, there are some valid reasons to use a user mode app to convert drive letters to volume guids.
But what happens when my driver restarts after a system restart. Do I need to run this app again to update the paths to driver? Or can I keep this information persist somewhere so that I don’t need to run the app again. I may be able to validate this info during instance setup. What is the usual practice?
Sajeev
Please, don’t send the same letter for me.
Thank you very much.
On 5/28/07, xxxxx@yahoo.com wrote:
>
> Ok, there are some valid reasons to use a user mode app to convert drive
> letters to volume guids.
>
> But what happens when my driver restarts after a system restart. Do I need
> to run this app again to update the paths to driver? Or can I keep this
> information persist somewhere so that I don’t need to run the app again. I
> may be able to validate this info during instance setup. What is the usual
> practice?
>
> Sajeev
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
You can use MountMgr to retrieve the drive letters (didn’t try), but your driver doesn’t get notitications when a drive letter CHANGES. Without some sort of polling your driver will have no idea the drive letter changed. Any way you handle it, there is a window of opportunity that some paths reported will
contain the old letter, or be converted to the old letter instead.
For this reason, we’re going GUID route lately with our driver. Customers confident in fixed drive letters can keep the “Easy” version, but more and more prefer GUID volume names.
xxxxx@yahoo.com wrote:
Ok, there are some valid reasons to use a user mode app to convert drive letters to volume guids.
But what happens when my driver restarts after a system restart. Do I need to run this app again to update the paths to driver? Or can I keep this information persist somewhere so that I don’t need to run the app again. I may be able to validate this info during instance setup. What is the usual practice?
–
Kind regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
Sajeev,
Since the volume GUID names are persistent, why don’t you create a key
in your filter drivers registry entry named for each volume GUID with
the list of directories on the particular volume you want to filter?
During instance setup you would then open the registry key for the
volume GUID and pull in the list.
Then you would have the application run whenever the data is changed for
a given volume?
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
xxxxx@yahoo.com wrote:
Ok, there are some valid reasons to use a user mode app to convert drive letters to volume guids.
But what happens when my driver restarts after a system restart. Do I need to run this app again to update the paths to driver? Or can I keep this information persist somewhere so that I don’t need to run the app again. I may be able to validate this info during instance setup. What is the usual practice?
Sajeev
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Pete
this makes perfect sense. I was trying to make sure that I’m not reinventing the wheel
thanks
Sajeev
Close, but I have seen cases where GUID changes. I cannot pinpoint why, but it seems that controllers give some different information when an array is reinstated, and the GUID changes.
Peter Scott wrote:
Sajeev,
Since the volume GUID names are persistent, why don’t you create a key
in your filter drivers registry entry named for each volume GUID with
the list of directories on the particular volume you want to filter?
During instance setup you would then open the registry key for the
volume GUID and pull in the list.Then you would have the application run whenever the data is changed for
a given volume?Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300xxxxx@yahoo.com wrote:
> Ok, there are some valid reasons to use a user mode app to convert drive letters to volume guids.
>
> But what happens when my driver restarts after a system restart. Do I need to run this app again to update the paths to driver? Or can I keep this information persist somewhere so that I don’t need to run the app again. I may be able to validate this info during instance setup. What is the usual practice?
>
> Sajeev
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Kind regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
Hello Sajeev
This subject comes up often and the conundrum seems to be … from filter
driver perspective I cant make sense of DOS drive letter … from client of
filter driver perspective I cant make sense of volume GUID. I dont have a
good answer 
Cheers
Lyndon
wrote in message news:xxxxx@ntfsd…
> My minifilter keeps track of changes to specified folders. I’m planning to
> have these folders specified in a configuration file. For now, I’m trying
> to avoid a user mode program to send these paths to the filter - the
> filter itself will read the configuration file.
>
> This works as long as I stick to paths with the full device names. But if
> I want to use drive letters I don’t see a easy way in minifilter to
> convert these drive letters to device names. Looks like MOUNTMGR ioctls
> can help in this conversion. My question is, is it save to use MOUNTMGR
> ioctls in a minifilter?
>
> Sajeev
>
Mount Manager works well if the system is fully started and a user logged
in. There are some interesting issues with dynamic volumes, but they are
not hard to handle if you understand Mount Manager calls. One rule that
works best is to not try and create a mount manager database in your own
driver that will be used for successive IRP_MJ_CREATEs.
–
David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation
“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Hello Sajeev
>
> This subject comes up often and the conundrum seems to be … from filter
> driver perspective I cant make sense of DOS drive letter … from client
> of filter driver perspective I cant make sense of volume GUID. I dont have
> a good answer
>
> Cheers
> Lyndon
>
> wrote in message news:xxxxx@ntfsd…
>> My minifilter keeps track of changes to specified folders. I’m planning
>> to have these folders specified in a configuration file. For now, I’m
>> trying to avoid a user mode program to send these paths to the filter -
>> the filter itself will read the configuration file.
>>
>> This works as long as I stick to paths with the full device names. But if
>> I want to use drive letters I don’t see a easy way in minifilter to
>> convert these drive letters to device names. Looks like MOUNTMGR ioctls
>> can help in this conversion. My question is, is it save to use MOUNTMGR
>> ioctls in a minifilter?
>>
>> Sajeev
>>
>
>
>
I’m confused. This is something like your fifth post like this. If
you’re requesting for people to not include you in a reply, you’ve got
the wrong list.
>> xxxxx@gmail.com 2007-05-28 11:05 >>>
Please, don’t send the same letter for me.
Thank you very much.
On 5/28/07, xxxxx@yahoo.com wrote:
>
> Ok, there are some valid reasons to use a user mode app to convert
drive
> letters to volume guids.
>
> But what happens when my driver restarts after a system restart. Do I
need
> to run this app again to update the paths to driver? Or can I keep
this
> information persist somewhere so that I don’t need to run the app
again. I
> may be able to validate this info during instance setup. What is the
usual
> practice?
>
> Sajeev
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com