UNC path syntax

UNC path syntax

[Tom Yonkman]

     Just started using the gnu-win32 package and wonder if ls and friends 
     can handle the UNC path syntax in some way? This would allow access to 
     machines in my "Network Neighborhood", as the explorer so quaintly 
     puts it.
     
     aTdHvAaNnKcSe,
     
     - ty -
     
     ******************************************************************
     * Tom Yonkman              email: tyonkman@elementalsoftware.com *
     * Elemental Software, Inc. phone: 760.931.7171 x3143             *
     * 5927 Priestly Drive      url: http://www.elementalsoftware.com *
     * Carlsbad, CA 92008       email2: tyonkman@cts.com              *
     ******************************************************************

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: UNC path syntax

[Ed Huott]

In message <34035660.1323@elementalsoftware.com>, Tom Yonkman writes:
>     Just started using the gnu-win32 package and wonder if ls and friends 
>     can handle the UNC path syntax in some way? This would allow access to 
>     machines in my "Network Neighborhood", as the explorer so quaintly 
>     puts it.
>     

No.  Nothing built with cygwin32 can deal with UNC path names.  The
cygwin32 approach requires that you map a drive to any remote (network
neighborhood) volumes.  Inside the bash shell, a mapped network drive
such as N: can then be referenced using the path "//N".  This syntax
can, unfortunately, collide with the most logical choice for
referencing a network share, which would be something like:
"//ComputerName/SharedDrive".

There is a unix-like volume mounting scheme that lets you acces a
drive as a sub-directory (i.e. N: ==> /DriveN) something like the old
DOS "join" command, but this works *only* for apps built with
cygwin32.

Lack of UNC support can be a real drawback if you're dealing in an
environment that uses a mix of both native (Windows) and cygwin32
apps.

<ED>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: UNC path syntax

[Jim Balter]

Ed Huott wrote:
> 
> In message <34035660.1323@elementalsoftware.com>, Tom Yonkman writes:
> >     Just started using the gnu-win32 package and wonder if ls and friends
> >     can handle the UNC path syntax in some way? This would allow access to
> >     machines in my "Network Neighborhood", as the explorer so quaintly
> >     puts it.
> >
> 
> No.  Nothing built with cygwin32 can deal with UNC path names.  The
> cygwin32 approach requires that you map a drive to any remote (network
> neighborhood) volumes.  Inside the bash shell, a mapped network drive
> such as N: can then be referenced using the path "//N".  This syntax
> can, unfortunately, collide with the most logical choice for
> referencing a network share, which would be something like:
> "//ComputerName/SharedDrive".
> 
> There is a unix-like volume mounting scheme that lets you acces a
> drive as a sub-directory (i.e. N: ==> /DriveN) something like the old
> DOS "join" command, but this works *only* for apps built with
> cygwin32.
> 
> Lack of UNC support can be a real drawback if you're dealing in an
> environment that uses a mix of both native (Windows) and cygwin32
> apps.

You can refer to UNC paths with, e.g., "\\xxx\y", but not
"//xxx/y", which gets turned into "c:\xxx\y".  You can use names like
"\\.\a:", but not "\\.\tape0", which gets turned into "c:\tape0".
And you cannot use UNCs in mounts; they get a \ appended that win32
can't handle.  I've attached a patch that fixes the latter two.
Among other things, this will allow you to read a local tape drive
on WinNT via tar, dd, etc. by using /dev/st0 if you fix the bogus mount
table entries (the proper name is "\\.\tape0", not "\\.\tape0:"):

umount /dev/st0
mount '\\.\tape0' /dev/st0
umount /dev/st1
mount '\\.\tape1' /dev/st1

Due to other bugs, this still does not allow you to write to local tape
via cygwin, however.

--
<J Q B>

Re: UNC path syntax

[Ed Huott]

In message < 3341A74E.627F@netcom.com >, Jim Balter writes:
>You can refer to UNC paths with, e.g., "\\xxx\y", but not
>"//xxx/y", which gets turned into "c:\xxx\y".  You can use names like

Are you sure about this?  With my (unpatched) copy of b17.1 running on
NT 3.51 or NT 4.0, cygwin's `ls' command fails when I use this syntax.
E.g.:

  C:\>ls \\newt\c
  ls: \\newt\c: No such file or directory

where "\\newt\c" is a valid share name on my network (i.e. I can do
`dir \\newt\c' and it works).

BTW, the behavior of `ls' invoked under bash is the same (with all \'s
properly escaped or quoted, of course! :-).  Please let me know if
there's something I'm missing here.

<ED>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Beta 18 timeframe, UNC path support

[Geoffrey Noer]

Tom Yonkman wrote:
> 
>      Just started using the gnu-win32 package and wonder if ls and friends 
>      can handle the UNC path syntax in some way? This would allow access to 
>      machines in my "Network Neighborhood", as the explorer so quaintly 
>      puts it.

UNC pathname support will be included in beta 18.

Also, I expect that the timeframe for beta 18 should be weeks rather than
months.

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: UNC path syntax

[Mikey]

I hate to be the bad news man, but this patch really messes up find.exe,
Sorry ;^).

> *** path.cc.orig	Sun Mar 23 02:15:12 1997
> --- path.cc	Sun Mar 23 03:15:33 1997
> ***************
> *** 208,214 ****
>   
>     /* The rule is :'s can't appear in [our] posix path names so this is
a safe
>        test; if ':' is present it already be in win32 form.  */
> !   if (strchr (src_path, ':') != NULL)
>       {
>         debug_printf ("conv_to_win32_path: %s already win32\n",
src_path);
>         if (win32_path != NULL)
> --- 208,216 ----
>   
>     /* The rule is :'s can't appear in [our] posix path names so this is
a safe
>        test; if ':' is present it already be in win32 form.  */
> !   // JQB: hack in test for \\ as well
> !   if (strchr (src_path, ':') != NULL ||
> !       src_path[0] == '\\' && src_path[1] == '\\')
>       {
>         debug_printf ("conv_to_win32_path: %s already win32\n",
src_path);
>         if (win32_path != NULL)
> ***************
> *** 305,313 ****
>   	{
>   	  int j = mount[i].devicelen;
>   	  memcpy (p, mount[i].device, j);
> ! 	  if (pathbuf[mount[i].pathlen] != '/')
>   	    p[j++] = '\\';
> ! 	  strcpy (p + j, pathbuf + mount[i].pathlen);
>   	  backslashify (p, p, trailing_slash_p);
>   	}
>         if (win32_path != NULL && ! got_rel_p && win32_path != p)
> --- 307,321 ----
>   	{
>   	  int j = mount[i].devicelen;
>   	  memcpy (p, mount[i].device, j);
> ! 
> ! 	  // JQB: add test for empty tail, so, for instance,
> ! 	  // \\.\tape0 doesn't turn into \\.\tape0\,
> ! 	  // which win32 doesn't like.  Still turn a: into a:\ though.
> ! 	  char *tail = pathbuf + mount[i].pathlen;
> ! 	  if ((*tail || tail[-1] == ':') && *tail != '/')
>   	    p[j++] = '\\';
> ! 	  strcpy (p + j, tail);
> ! 
>   	  backslashify (p, p, trailing_slash_p);
>   	}
>         if (win32_path != NULL && ! got_rel_p && win32_path != p)
> 
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".