Access a local drive without a drive letter?

[Bert]

Windows XP Pro SP3

Is there any way, from the command line or programatically, to access
files on a drive which doesn't have a drive letter assigned?

It's a normal drive, local to this machine, with an NTFS file system and
ordinary directories and files, but has had the drive letter removed.

Yes, I can assign a drive letter if I need to, but I'd just like to know
if I really must.

 

[Paul]

Windows XP Pro SP3

Is there any way, from the command line or programatically, to access
files on a drive which doesn't have a drive letter assigned?

It's a normal drive, local to this machine, with an NTFS file system and
ordinary directories and files, but has had the drive letter removed.

Yes, I can assign a drive letter if I need to, but I'd just like to know
if I really must.

mountvol /?

should list the GUID for the volumes. I notice the values are
different, using that command, than looking in HKLM\System\MountDevices.

They show an attempt to access a volume via GUID, here.

http://virtuallyaware.wordpress.com/2008/07/23/volume-guids-ways-to-viewaccess-the-files-within/

First, mountvol returned this...

"Possible values for VolumeName along with current mount points are:

\\?\Volume{ed012da7-78f1-11e0-a53f-001fc68cdcf4}\

"

And then in DOS, I did...

dir \\?\Volume{ed012da7-78f1-11e0-a53f-001fc68cdcf4}\\

and it listed the files on the root of that volume.

Mountvol should only return info for things with a mapping, so
you might need to assign a letter, run mountvol, write down the
value, remove the drive letter, and see what happens.

Just a guess,
Paul

 

[Bert]

...
And then in DOS, I did...

dir \\?\Volume{ed012da7-78f1-11e0-a53f-001fc68cdcf4}\\

and it listed the files on the root of that volume.

Mountvol should only return info for things with a mapping, so
you might need to assign a letter, run mountvol, write down the
value, remove the drive letter, and see what happens.

It actually returned a GUID for the drive even with no drive letter
assigned:

\\?\Volume{a77dedca-9bd3-11de-a353-001a92dfb24b}\
*** NO MOUNT POINTS ***

And using the DIR command as you showed did list the contents of the
drive. Appending directory names and file names to the end of the
string did the expected things too.

Just a guess,
Paul

And a good one.

Thanks.

 

[David H. Lipman]

mountvol /?

should list the GUID for the volumes. I notice the values are
different, using that command, than looking in HKLM\System\MountDevices.

They show an attempt to access a volume via GUID, here.

http://virtuallyaware.wordpress.com/2008/07/23/volume-guids-ways-to-viewaccess-the-files-within/

First, mountvol returned this...

"Possible values for VolumeName along with current mount points are:

\\?\Volume{ed012da7-78f1-11e0-a53f-001fc68cdcf4}\

"

And then in DOS, I did...

dir \\?\Volume{ed012da7-78f1-11e0-a53f-001fc68cdcf4}\\

and it listed the files on the root of that volume.

Mountvol should only return info for things with a mapping, so
you might need to assign a letter, run mountvol, write down the
value, remove the drive letter, and see what happens.

Just a guess,
Paul

Very cool.

I did not know this - Thanx!

 

[NimbUs]

mountvol /?
They show an attempt to access a volume via GUID

.......

Like others said, this is cool. Raises immediate questions
however; maybe you or others can tell :

- does write access work the same or is that read only ?
- is data accessed in this way going thru the Windows cache or
is caching bypassed (even for read only access) ?
- do known applications, and/or Windows itself, routinely use
driveletter-less access for their own purpose ?

Reason I am asking you (you all!) is because I used to believe
that Windows will not access, even less cache, data from
partitions without a drive letter assigned "behind our back" so
to say. I relied on this belief while accessing parts of my main
hard disk(s) in "raw" mode from within virtual machines (I use
mostly VMware on Windows XP 3, could as well be Virtual Box or
similar). Now I'm worried !

 

[Uwe Sieber]

......

Like others said, this is cool. Raises immediate questions
however; maybe you or others can tell :

- does write access work the same or is that read only ?
- is data accessed in this way going thru the Windows cache or
is caching bypassed (even for read only access) ?
- do known applications, and/or Windows itself, routinely use
driveletter-less access for their own purpose ?

Reason I am asking you (you all!) is because I used to believe
that Windows will not access, even less cache, data from
partitions without a drive letter assigned "behind our back" so
to say. I relied on this belief while accessing parts of my main
hard disk(s) in "raw" mode from within virtual machines (I use
mostly VMware on Windows XP 3, could as well be Virtual Box or
similar). Now I'm worried !

A volume name like Volume{06588845-39a4-11e0-8027-806d6172696f}
is exactly the same thing as a drive letter like "C:". Both
are symbolic links which point to the volume's kernel object,
something like \Device\HarddiskVolume1.
The \\?\ prefix is for skipping the resolving of relative
paths. This is required because Volume{UUID} is a pretty valid
file name and without the prefix Windows would look for a
file with this name in the current directory. For drive letters
this is hard coded. Therefore you cannot access an NTFS stream
in a file named with a single letter. C:X would be a valid name
for an stream X in file C but C: makes it resoved as drive spec
plus X.
Back to your question... It's about a volume being mounted or
not. Windows does not mount volumes without a drive letter
because no one is accessing it in real live. But if indeed
someone comes and accesses e.g.
\\?\Volume{06588845-39a4-11e0-8027-806d6172696f}\boot.ini
then even a volume without a drive letter is auto-mounted.
But all the nasty Windows background stuff relies on
drive letters, therefore this does not happen in real life.
And VMWARE should just dismount the accessed volumes and
warn you if this fails.

You can try yourself:
http://www.uwe-sieber.de/files/createfiletest.zip
Determine your volume's volume name, and open a file like
\\?\Volume{06588845-39a4-11e0-8027-806d6172696f}\boot.ini

VMWARE should complain then when it tries to dismount the
volume.


Uwe

 

[NimbUs]

A volume name like Volume{06588845-39a4-11e0-8027- 806d6172696f}
is exactly the same thing as a drive letter like "C:". Both
are symbolic links which point to the volume's kernel object,
something like \Device\HarddiskVolume1.
The \\?\ prefix is for skipping the resolving of relative
paths. This is required because Volume{UUID} is a pretty valid
file name and without the prefix Windows would look for a
file with this name in the current directory. For drive letters
this is hard coded. Therefore you cannot access an NTFS stream
in a file named with a single letter. C:X would be a valid name
for an stream X in file C but C: makes it resoved as drive spec
plus X.

Interesting. Next :

Back to your question... It's about a volume being mounted or
not. Windows does not mount volumes without a drive letter
because no one is accessing it in real live. But if indeed
someone comes and accesses e.g.
\\?\Volume{06588845-39a4-11e0-8027-806d6172696f}\boot.ini
then even a volume without a drive letter is auto-mounted.
But all the nasty Windows background stuff relies on
drive letters, therefore this does not happen in real life.
And VMWARE should just dismount the accessed volumes and
warn you if this fails.

Nice but there is a detail which you (maybe) overlooked and
which may be important : my VM is /not/ mounting one or more
individual raw partitions ("volumes" in your and MS's
terminology), rather it's set up to access the whole hard disk
("raw" disk in VMware parlance). In other words, VMware accesses
not files, but sectors - so the question arises again, is that
secure ? /Of course/ I am careful not to have the OS inside the
virtual machine mount or access any data belonging to partitions
that are currently used by or mounted (by letter) in the host's
Windows OS.

You can try yourself:
http://www.uwe-sieber.de/files/createfiletest.zip
Determine your volume's volume name, and open a file like
\\?\Volume{06588845-39a4-11e0-8027-806d6172696f}\boot.ini

Nice, shall do.

VMWARE should complain then when it tries to dismount the
volume.

As said above, VMware is /not/ told to mount any /volume/, so I
can't see things happenning this way.

But of course worse things might happen /if/ Windows (or some
brain dead app) was to change things on parts of the disk which
it shouldn't. Hopefully this has no reason to happen, barring
the presence of malware...

 

[Uwe Sieber]

Nice but there is a detail which you (maybe) overlooked and
which may be important : my VM is /not/ mounting one or more
individual raw partitions ("volumes" in your and MS's
terminology), rather it's set up to access the whole hard disk
("raw" disk in VMware parlance). In other words, VMware accesses
not files, but sectors - so the question arises again, is that
secure ?

It is safe only if all volumes on this disk have been locked and
dismounted, otherwise write access is unsafe. Therefore I'm sure
that VM does lock and dismount all volumes on disk it intends to
write to.

As said above, VMware is /not/ told to mount any /volume/, so I
can't see things happenning this way.

Then what is the raw access good for other than finding partitions
with file systems and mount them?


Uwe

 

[NimbUs]

Uwe Sieber wrote :

It is safe only if all volumes on this disk have been locked and
dismounted, otherwise write access is unsafe. Therefore I'm sure
that VM does lock and dismount all volumes on disk it intends to
write to.

No I'm sorry, it will /not/ lock or dismount anything in the
host. This is the whole point of raw disks.

Then what is the raw access good for other than finding partitions
with file systems and mount them?

We must make clear distinctions here. Using raw access, VMware
does not look for, dismount, mount or access any partitions
using the host OS or otherwise; guest systems, booted inside a
VM, on the other hand /will/ likely mount look for, mount and
access any partitions that they are set to recognise.

It's up to the user, to set 'things' up both in the host and the
guests so that no conflicts can arise. It can be hairy, but I've
been playing this kind of game for over 10 years with zero
problem (crossing fingers)...

Back to the point : since removing all drive letters from the
partition in question is not enough, as you have pointed out, at
least in theory... is there a way to tell Windows XP to leave a
partition /really/ alone ?

 

[Uwe Sieber]

Uwe Sieber wrote :



No I'm sorry, it will /not/ lock or dismount anything in the
host. This is the whole point of raw disks.


We must make clear distinctions here. Using raw access, VMware
does not look for, dismount, mount or access any partitions
using the host OS or otherwise; guest systems, booted inside a
VM, on the other hand /will/ likely mount look for, mount and
access any partitions that they are set to recognise.

It's up to the user, to set 'things' up both in the host and the
guests so that no conflicts can arise. It can be hairy, but I've
been playing this kind of game for over 10 years with zero
problem (crossing fingers)...

Back to the point : since removing all drive letters from the
partition in question is not enough, as you have pointed out, at
least in theory... is there a way to tell Windows XP to leave a
partition /really/ alone ?

Yes, you can deacitivat the partition's volume device.
http://www.uwe-sieber.de/files/listusbdrives.zip

Started thru the included ListUsbDrives_To_Notepad.cmd it lists
all types of drives. For each drive it shows the "Volume DevID",
something like "STORAGE\VOLUME\1&30A96598&0&SIGNATUREAF67AF.......".

You can use this with Microsoft DEVCON command line tool:
http://support.microsoft.com/kb/311272

Enclose the id in quotation marks and set an @ in front:
DEVCON disable "@STORAGE\VOLUME\1&30A96598&0&SIGNATUREAF67AF67....."
^

Or search the volume in the device manager and deactivate it there.


Uwe

 

[NimbUs]

Yes, you can deacitivat the partition's volume device.
http://www.uwe-sieber.de/files/listusbdrives.zip

Nice tool, thank you very much ...

For each drive it shows the "Volume DevID",
something like "STORAGE\VOLUME\1&30A96598&0 &SIGNATUREAF67AF.......".

You can use this with Microsoft DEVCON command line tool:
http://support.microsoft.com/kb/311272

Enclose the id in quotation marks and set an @ in front:
DEVCON disable "@STORAGE\VOLUME\1&30A96598&0

&SIGNATUREAF67AF67....."

Good. I had devcon in the past (and lost it), never used it
much.
As you're familiar with that tool, can you tell whether the
disabling it achieves in Windows is persistent across reboots ?

Or search the volume in the device manager and deactivate it

there.

Oh, of course, what would we do without our GUI toys <G>
I did /not/ find a way to disable individual volumes in dev
manager though. Not saying there isn't one...

Again /danke sehr/, Uwe.

 

[Uwe Sieber]

&SIGNATUREAF67AF67....."

Good. I had devcon in the past (and lost it), never used it
much.
As you're familiar with that tool, can you tell whether the
disabling it achieves in Windows is persistent across reboots ?

Yes, last time I tried it was persistent.

there.

Oh, of course, what would we do without our GUI toys <G>
I did /not/ find a way to disable individual volumes in dev
manager though. Not saying there isn't one...

Yes, you have to activate "View" -> "Show hidden devices"
Then it lists all volumes as "Generic volume" under "Storage volumes".


Uwe

 

[NimbUs]

Uwe Sieber said :

Yes, you have to activate "View" -> "Show hidden devices"
Then it lists all volumes as "Generic volume" under "Storage

volumes".

Aha, "hidden" devices, of coarse ;=) ... right, you got my vote.
Starting immediately, I'm using this protection method for
volumes I will access from the VMs.