Mail Archives: cygwin/1997/04/02/03:29:48
This is a multi-part message in MIME format.
--------------7D0C37723737
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ed Huott wrote:
>
> In message <34035660 DOT 1323 AT elementalsoftware DOT 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>
--------------7D0C37723737
Content-Type: text/plain; charset=us-ascii; name="path.UNCpatch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="path.UNCpatch"
*** 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)
--------------7D0C37723737--
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -