Accessing GLOBALROOT paths - a potential compromise???

[Jeffrey J. Kosowsky]

I know that there have been multiple threads about the pros/cons of
being able to access XP/Vista style \\?\GLOBALROOT paths.

However, not being able to access them limits one's abilities to use
things like shadow copies since they create shadow devices that are only
accessible by such a path. For example
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1

The only hack that I have found to get around this is to use an *old*,
*unsupported* Microsoft routine called 'dosdev' which allows you to
assign drive letters to devices, including using the GLOBALROOT
format.

However, it has several disadvantages:
- It is old and not available
- It is unsupported
- It is mostly undocumented with different versions and command lines
for different Windows OS's -- so it is not portable across Windows
implementations (neither is vshadow.exe but that is another issue)
- It is not cygwin (and requires DOS type '/' parameters)
- It requires login access so it won't work with ssh login with
username=SYSTEM

If the cygwin developers are worried about performance or bug issues
with adding the GLOBALROOT syntax to *all* file operations, how about
implementing one of the two below compromises:

1. Just allow the GLOBALROOT implementation for mount.
This would allow you to mount the device using a drive letter and
then access it that way (similar to dosdev.exe itself).

2. If you don't want to touch mount itself, then how about writing an
alternative restrictive version of mount called something else that
just handles the special case of assigning/mounting a drive letter
to the GLOBALROOT device -- i.e. basically implementing the dosdev
functionality in a cygwin way.

Alternatively, is there any other way (other than dosdev.exe to access
global root partitions)

[Corinna Vinschen]

Post by Jeffrey J. Kosowsky
I know that there have been multiple threads about the pros/cons of
being able to access XP/Vista style \\?\GLOBALROOT paths.
However, not being able to access them limits one's abilities to use
things like shadow copies since they create shadow devices that are only
accessible by such a path. For example
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1

In Cygwin 1.7 you can do this for any subdir in your volume shadow copy:

$ ls -l //?/GLOBALROOT/Device/HarddiskVolumeShadowCopy1/subdir

It just doesn't work for the root directory of a drive due to internal
path handling restrictions. But there's a simple workaround. Use your
own tool as below.

Post by Jeffrey J. Kosowsky
The only hack that I have found to get around this is to use an *old*,
*unsupported* Microsoft routine called 'dosdev' which allows you to
assign drive letters to devices, including using the GLOBALROOT
format.

Try this:

$ cat > DefDosDevice.c << EOF
#include <stdio.h>
#include <windows.h>

int
main (int argc, char **argv)
{
DWORD flags = 0;

if (argc < 2)
{
fprintf (stderr, "usage: %s DosDevice [NTDevice]\n", argv[0]);
return 1;
}
if (argc == 2)
flags = DDD_REMOVE_DEFINITION;
else
flags = DDD_RAW_TARGET_PATH;
if (!DefineDosDevice (flags, argv[1], argc == 2 ? NULL : argv[2]))
{
fprintf (stderr, "Error %d\n", GetLastError ());
return 1;
}
return 0;
}
EOF
$ gcc DefDosDevice.c -o DefDosDevice
$ ./DefDosDevice X: '\??\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
$ cd /mnt/x
$ ls
[...]
$ cd /mnt/c
$ ./DefDosDevice X: # this deletes drive X: again

Drive X: is not visible in Explorer, but you can access it from CMD and
any Cygwin process just fine. To make it visible in Explorer, assign
another drive letter using subst:

$ cmd /c subst W: X:\\

Afterwards you can access drive X: as drive W: from Explorer which,
for some reason, thinks it's accessing a "RAM Disk" on Windows 7.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen
$ ./DefDosDevice X: '\??\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
$ cd /mnt/x

Oops... replace /mnt/x with /cygdrive/x. I have changed my cygdrive
prefix to /mnt locally. Sorry for any confusion.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Corinna Vinschen
$ ./DefDosDevice X: '\??\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
$ cd /mnt/x

Oops... replace /mnt/x with /cygdrive/x. I have changed my cygdrive
prefix to /mnt locally. Sorry for any confusion.

Out of curiosity I experimented some more with this, and it's
even more simple than that. Defining X: like this:

$ ./DefDosDevice X: '\Device\HarddiskVolumeShadowCopy1'

works out of the box, even with Windows Explorer.


Corinna

[aputerguy]

Post by Corinna Vinschen
$ ls -l //?/GLOBALROOT/Device/HarddiskVolumeShadowCopy1/subdir
It just doesn't work for the root directory of a drive due to internal
path handling restrictions. But there's a simple workaround. Use your
own tool as below.
The only hack that I have found to get around this is to use an *old*,
*unsupported* Microsoft routine called 'dosdev' which allows you to
assign drive letters to devices, including using the GLOBALROOT
format.
$ cat > DefDosDevice.c << EOF

Cool....
Two follow-up questions:
1. Any idea how this differs from dosdev.exe? Is it faster/slower? More/less
robust? More/less portable?
2. Should this short routine be added somewhere in the cygwin distribution?
It seems incredibly useful and simple.

[Corinna Vinschen]

Post by aputerguy

Post by Corinna Vinschen
$ ls -l //?/GLOBALROOT/Device/HarddiskVolumeShadowCopy1/subdir
It just doesn't work for the root directory of a drive due to internal
path handling restrictions. But there's a simple workaround. Use your
own tool as below.
The only hack that I have found to get around this is to use an *old*,
*unsupported* Microsoft routine called 'dosdev' which allows you to
assign drive letters to devices, including using the GLOBALROOT
format.
$ cat > DefDosDevice.c << EOF

Cool....
1. Any idea how this differs from dosdev.exe? Is it faster/slower? More/less
robust? More/less portable?

No idea. It works, right?

Post by aputerguy
2. Should this short routine be added somewhere in the cygwin distribution?
It seems incredibly useful and simple.

It's especially incredible trivial. There's also nothing
Cygwin-specific in it. Just build it for yourself if you need it.


Corinna

[aputerguy]

Post by Corinna Vinschen

Post by aputerguy
2. Should this short routine be added somewhere in the cygwin
distribution?
It seems incredibly useful and simple.

It's especially incredible trivial. There's also nothing
Cygwin-specific in it. Just build it for yourself if you need it.

Yes it is trivial but since I am distributing my script to others, it would
be nice if it didn't require additional binaries.... and this seems like
pretty basic functionality particularly given the GLOBALROOT limitations of
the cygwin implementation.

Not a terribly big deal though just a suggestion...