I have three questions:
THanks
–
Short answer:
Yes (to all three): Mount points.
Have a look at disk management (inside Computer management in WXP) action->
Change Drive letters And paths…
/rod
Absolutely. Bear in mind that the drive letter mapping is per SESSION. Thus, one user can have a-z mapped to one set of drives, and a different user can have a-z mapped to an entirely different set of drives.
Absolutely. See the Win32 function DefineDosDevice as but one possible approach. For another approach, consider the native NT API.
See the answer to item 2.
Peter
OSR
> 1. Can windows support more than 26 drives (A:…Z:) ?
Yes. To hide a drive from a “normal” user, I created 1: or 2: or
whatever, they were never seen in Explorer but
dir 8:\someFolder*.txt
or
copy C:\file.fle 9:\saved|file.fle
works ok.
- Is there any way to open a file from usermode which lies in
a device whose DosDevice symbolic link (C:, etc) doesn’t exist?
Yes. In addition to what has been said, fully qualified name works ok,
like:
// first figure it out:
// mountvol G:/ /l
// \?\Volume{946779ec-fe9b-11d8-a5d7-505054503030}\
// results:
/* with G: dismounted:
failed to open G:\try.me
read \?\Volume{946779ec-fe9b-11d8-a5d7-505054503030}\try.me ok
*/
/** with G: mounted:
read G:\try.me ok
read \?\Volume{946779ec-fe9b-11d8-a5d7-505054503030}\try.me ok
**/
----- Original Message -----
From: amitr0
To: Windows File Systems Devs Interest List
Sent: Saturday, March 25, 2006 10:43 AM
Subject: [ntfsd] 3 questions
I have three questions:
THanks
–
Hello everybody,
Thanks for all the replies, this information is very useful.
"Yes (to all three): Mount points.
Have a look at disk management (inside Computer management in WXP) action->
Change Drive letters And paths…"
Yes, rod, i did check it, before I posted the questions…
“Absolutely. Bear in mind that the drive letter mapping is per SESSION.
Thus, one user can have a-z mapped to one set of drives, and a different
user can have a-z mapped to an entirely different set of drives.”
Peter, by “per session” you mean that if two users are logged into the
same machine at the same time (terminal services/telnet) then there can be
two different sets of drive mappings?
If a volume is mounted inside an NTFS folder, then what is the mechanism
theIO manager uses to resolve the device to which the IRP is going to be
sent? Would the IRP be sent to the base device (into which I mounted) and
then be rerouted to the actual device using anotehr IRP, or does the object
manager resolve the symbolic link and send the IRp directly down to the
concerned device?
amitr0
> by “per session” you mean that if two users are logged into the
same machine at the same time (terminal services/telnet) then there can be
two different sets of drive mappings?
Yes, DosDevices is in per session space and the object manager knows to
look there for ??\
- If a volume is mounted inside an NTFS folder, then what is the
mechanism
theIO manager uses to resolve the device to which the IRP is going to be
sent? Would the IRP be sent to the base device (into which I mounted) and
then be rerouted to the actual device using anotehr IRP, or does the
object
manager resolve the symbolic link and send the IRp directly down to the
concerned device?
(Sort of) yes to both. The IRP is sent to NTFS (or any other filesystem
which supportsthe concept) which looks as sees that that somewhere along the
path there is a mount point. It therefore sets up some information (which
includes the actual device address) into Irp->Tail.Overlay.AuxiliarryBuffer
and then returns with Iosb->Status=STATUS_REPARSE
Iosb->Information=IO_REPARSE_TAG_MOUNT_POINT.
The IO Manager looks out for that status/information pair, rebuilds the name
into the file object appropriately and restarts the parse process from the
top.
Rod,
What is say is very very interesting…
"Yes, DosDevices is in per session space and the object manager knows to
look there for ??"
In the kernel mode (with ternimal services running and multiple users logged
in) if I do an IoVolumeDeviceToDosName(…) then will I get different
mappings for different therads(initiated by different users)? What I mean
is, say if user-A is loacally logged on and does a copy operation from d: to
e: and if a terminal serer user is logged on and has e: mounted as f: in his
session, and does a copy op from d: f: then in my FSFD code if I want to
catch the IRP write for user A and terminal services user, then would
IoVolumeDeviceToDosName retuen dirrerent values (E and f:) to me?
“(Sort of) yes to both. The IRP is sent to NTFS (or any other filesystem
which supportsthe concept) which looks as sees that that somewhere along the
path there is a mount point.”
How do I detect that in the path is a mount point? Is there something in the
name? Or some flags?
" It therefore sets up some information (which
includes the actual device address) into Irp->Tail.Overlay.AuxiliarryBuffer
and then returns with Iosb->Status=STATUS_REPARSE
Iosb->Information=IO_REPARSE _TAG_MOUNT_POINT."
Can you define “some information” more accurately, what all are done. Is
there someplase I could rad up on them.
“The IO Manager looks out for that status/information pair, rebuilds the
name
into the file object appropriately and restarts the parse process from the
top.”
So One IRP goes up, and then again comes down with a different device
name??? Does this mean that in filespy I would see two differeent read
op logs for the same read (ofcourse with different flags to distinguish
them)?
Reparse is processed on IRP_MJ_CREATE not IRP_MJ_READ.
A caller has no idea there will be a mount point, so until you see the
STATUS_REPARSE in your filter you wouldn’t know either. The difference
is that your filter will see the STATUS_REPARSE but the original caller
will not.
Hint when trying to find data structure declarations - look in ntifs.h.
Even if you are using NOTEPAD as your programming editor, it does have a
search function and searching for the tag REPARSE turns up:
typedef struct _REPARSE_DATA_BUFFER {
ULONG ReparseTag;
USHORT ReparseDataLength;
USHORT Reserved;
union {
struct {
USHORT SubstituteNameOffset;
USHORT SubstituteNameLength;
USHORT PrintNameOffset;
USHORT PrintNameLength;
WCHAR PathBuffer[1];
} SymbolicLinkReparseBuffer;
struct {
USHORT SubstituteNameOffset;
USHORT SubstituteNameLength;
USHORT PrintNameOffset;
USHORT PrintNameLength;
WCHAR PathBuffer[1];
} MountPointReparseBuffer;
struct {
UCHAR DataBuffer[1];
} GenericReparseBuffer;
};
} REPARSE_DATA_BUFFER, *PREPARSE_DATA_BUFFER;
(which is itself a superstructure that overlays nicely with
REPARSE_GUID_DATA_BUFFER the structure following it in ntifs.h). AND
you will find some comments about all of this - data structures, reparse
point tags, GUIDs, etc. in the ntifs.h header file.
I think there are other discussions and articles on this topic on
OSRONLINE but I’ll leave the exercise of searching for them (heck, you
can even find them in Google) to you.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 18-21, 2006.
TYhanks tony…
In the kernel mode (with ternimal services running and multiple users logged
in) if I do an IoVolumeDeviceToDosName(…) then will I get different
mappings for different therads(initiated by different users)? What I mean
is, say if user-A is loacally logged on and does a copy operation from d: to
e: and if a terminal serer user is logged on and has e: mounted as f: in his
session, and does a copy op from d: f: then in my FSFD code if I want to
catch the IRP write for user A and terminal services user, then would
IoVolumeDeviceToDosName retuen dirrerent values (E and f:) to me?
amitr0
Yes it should. IIRC, drive letter mappings are on session basis only on
winxp onwards. On win2k, they are global.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Monday, March 27, 2006 8:04 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] 3 questions
TYhanks tony…
In the kernel mode (with ternimal services running and multiple users
logged in) if I do an IoVolumeDeviceToDosName(…) then will I get
different mappings for different therads(initiated by different users)?
What I mean is, say if user-A is loacally logged on and does a copy
operation from d: to e: and if a terminal serer user is logged on and
has e: mounted as f: in his session, and does a copy op from d: f: then
in my FSFD code if I want to catch the IRP write for user A and terminal
services user, then would IoVolumeDeviceToDosName retuen dirrerent
values (E and f:) to me?
amitr0
— Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed
to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a
blank email to xxxxx@lists.osr.com
Interesting… Say I have two partitions on my HDD, C: and D:. So it is
possible for another logged on user to see these partitions only as Y and Z?
How can I achieve this in practice? Can this be done via Control Panel or
Disk Management?
What about IOCTL_MOUNTMGR_QUERY_POINTS? Are you saying it returns different
results depending on the current session?
–
wrote in message news:xxxxx@ntfsd…
>
>
> Absolutely. Bear in mind that the drive letter mapping is per SESSION.
> Thus, one user can have a-z mapped to one set of drives, and a different
> user can have a-z mapped to an entirely different set of drives.
This just requires adding the drive letter in the session’s device map
space (DefineDosDevice should do this for you.) I’ve seen this happen
in the “real world” a couple of times with unintended consequences.
Suppose you have a hard drive “C:” and CD-ROM drive “D:”. Try mapping a
network share to “E:”. This works (no conflict) and life is good. Then
attach a USB drive (“pen drive”). The OS notices that “E:” is not used
(in the base name space) and assigns it to the drive - voila! You can’t
access the underlying drive in that name space.
The general “model” though is that local drives are available to all
sessions, while network drives are only visible in the specific session
in which it was created.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 18-21, 2006.
>1. Can windows support more than 26 drives (A:…Z:) ?
You can also use mount points and \?\Volume{guid}\path\file.ext syntax.
- Is there any way to open a file from usermode which lies in a device
whose DosDevice symbolic link (C:, etc) doesn’t exist?
Yes, by using \?\Volume{guid}\path\file.ext syntax. You will need the volume
GUID anyway though.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
>1. Peter, by “per session” you mean that if two users are logged into the
same machine at the same time (terminal services/telnet) then there can be
two different sets of drive mappings?
Yes.
- If a volume is mounted inside an NTFS folder, then what is the mechanism
theIO manager uses to resolve the device to which the IRP is going to be
sent?
First, the MJ_CREATE path is called on parent NTFS volume. During path
traversing, NTFS hits the special on-disk record of “reparse point”. The record
contains some tag value, which denotes the way of interpreting it, and also
some data piece. For a standard tag value (which means - “another volume is
mounted here”) - the data piece is the child volume’s GUID name.
Then NTFS sets something in the file object (->FileName???) to the data piece
from the on-disk reparse point, sets Irp->IoStatus.Status to STATUS_REPARSE and
Irp->IoStatus.Information to the tag value from the reparse point. Then NTFS
completes the MJ_CREATE request.
For custom tag values, there must be a filter driver above NTFS, which catches
such a way of MJ_CREATE completion and does its own processing based on the
“data piece” from the NTFS reparse point.
But, for a standard tag value (forgotten its name in C language) - the
completion unrolls up to the IO manager itself, which does the following in
this case of STATUS_REPARSE + standard tag:
Now remember that, for a standard tag value, the data piece is the volume GUID
name. So, this IO manager’s processing redirects the path traversing to a root
of some volume.
This is how NTFS reparse points work.
NOTE: volume GUID name is a must for a properly supported (FindNextVolume works
etc) drive letter in w2k+, as also for being a target of the reparse point.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
maxim,
Thanks for explaining so well…