Accessing GLOBALROOT paths - a potential compromise???

View: New views
7 Messages — Rating Filter:   Alert me  

Accessing GLOBALROOT paths - a potential compromise???

by Jeffrey J. Kosowsky-12 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Re: Accessing GLOBALROOT paths - a potential compromise???

by Corinna Vinschen-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Nov  3 01:49, Jeffrey J. Kosowsky wrote:
> 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.
 
> 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                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Re: Accessing GLOBALROOT paths - a potential compromise???

by Corinna Vinschen-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Nov  3 16:44, Corinna Vinschen wrote:
>   $ ./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                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Re: Accessing GLOBALROOT paths - a potential compromise???

by Corinna Vinschen-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Nov  3 16:54, Corinna Vinschen wrote:
> On Nov  3 16:44, Corinna Vinschen wrote:
> >   $ ./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

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Re: Accessing GLOBALROOT paths - a potential compromise???

by aputerguy :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Corinna Vinschen writes:

> 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.
>
> 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

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.

Re: Accessing GLOBALROOT paths - a potential compromise???

by Corinna Vinschen-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Nov  5 13:41, aputerguy wrote:

>
> Corinna Vinschen writes:
>
> > 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.
> >
> > 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
>
> Cool....
> Two follow-up questions:
> 1. Any idea how this differs from dosdev.exe? Is it faster/slower? More/less
> robust? More/less portable?

No idea.  It works, right?

> 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

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Re: Accessing GLOBALROOT paths - a potential compromise???

by aputerguy :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Corinna Vinschen writes:
> Jeff Kosowsky writes:
>> 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...