Add support for creating native windows symlinks

Add support for creating native windows symlinks

[Russell Davis]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

This was discussed before here:
http://cygwin.com/ml/cygwin/2008-03/msg00277.html

These were the reasons given for not using native symlinks to create
cygwin symlinks, along with my responses:

- By default, only administrators have the right to create native
  symlinks.  Admins running with restricted permissions under UAC don't
  have this right.

This is true, however the feature can be made optional through the
CYGWIN environment variable (just like winsymlinks). For users that
can add the permission or disable UAC, the use of native symlinks is a
huge step towards making cygwin more unified with the rest of Windows.

- When creating a native symlink, you have to define if this symlink
  points to a file or a directory.  This makes no sense given that
  symlinks often are created before the target they point to.

Also true. However, the type only matters for Windows' usage of the
symlink -- cygwin already treats both the types the same. For example,
if a native symlink of type `file` actually points to a directory, it
will still work fine inside cygwin. It won't work for Win32 programs
that try to access it, but that's still no worse than the status quo
-- Win32 programs already can't use cygwin symlinks.

Since cygwin already supports reading of native symlinks, I was able
to add support for this with a fairly small change. Some edge cases
probably still need to be handled (disabling for older versions of
windows and unsupported file systems), but I wanted to get this out
there for review. The patch is attached.

Cheers,
Russell Davis

[-- Attachment #2: symlinks.patch --]
[-- Type: application/octet-stream, Size: 4959 bytes --]

Index: cygwin/environ.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/environ.cc,v
retrieving revision 1.196
diff -u -p -r1.196 environ.cc
--- cygwin/environ.cc	21 Aug 2011 18:45:07 -0000	1.196
+++ cygwin/environ.cc	4 Dec 2011 06:17:15 -0000
@@ -35,6 +35,7 @@ details. */
 extern bool dos_file_warning;
 extern bool ignore_case_with_glob;
 extern bool allow_winsymlinks;
+extern bool allow_nativesymlinks;
 bool reset_com = false;
 
 static char **lastenviron;
@@ -124,6 +125,7 @@ static struct parse_thing
   {"reset_com", {&reset_com}, justset, NULL, {{false}, {true}}},
   {"tty", {func: tty_is_gone}, isfunc, NULL, {{0}, {0}}},
   {"winsymlinks", {&allow_winsymlinks}, justset, NULL, {{false}, {true}}},
+  {"nativesymlinks", {&allow_nativesymlinks}, justset, NULL, {{false}, {true}}},
   {NULL, {0}, justset, 0, {{0}, {0}}}
 };
 
Index: cygwin/path.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/path.cc,v
retrieving revision 1.640
diff -u -p -r1.640 path.cc
--- cygwin/path.cc	3 Dec 2011 21:43:26 -0000	1.640
+++ cygwin/path.cc	4 Dec 2011 06:17:15 -0000
@@ -1413,16 +1413,17 @@ conv_path_list (const char *src, char *d
 /* If TRUE create symlinks as Windows shortcuts, if false create symlinks
    as normal files with magic number and system bit set. */
 bool allow_winsymlinks = false;
+bool allow_nativesymlinks = false;
 
 extern "C" int
 symlink (const char *oldpath, const char *newpath)
 {
-  return symlink_worker (oldpath, newpath, allow_winsymlinks, false);
+  return symlink_worker (oldpath, newpath, allow_winsymlinks, allow_nativesymlinks, false);
 }
 
 int
 symlink_worker (const char *oldpath, const char *newpath, bool use_winsym,
-		bool isdevice)
+		bool use_nativesym, bool isdevice)
 {
   int res = -1;
   size_t len;
@@ -1436,7 +1437,8 @@ symlink_worker (const char *oldpath, con
   ULONG access = DELETE | FILE_GENERIC_WRITE;
   tmp_pathbuf tp;
   unsigned check_opt;
-  bool mk_winsym = use_winsym;
+  bool mk_winsym = use_winsym && !use_nativesym;
+  bool mk_nativesym = use_nativesym;
   bool has_trailing_dirsep = false;
 
   /* POSIX says that empty 'newpath' is invalid input while empty
@@ -1471,8 +1473,12 @@ symlink_worker (const char *oldpath, con
   win32_newpath.check (newpath, check_opt, stat_suffixes);
   /* MVFS doesn't handle the SYSTEM DOS attribute, but it handles the R/O
      attribute.  Therefore we create symlinks on MVFS always as shortcuts. */
-  mk_winsym |= win32_newpath.fs_is_mvfs ();
-
+  if (win32_newpath.fs_is_mvfs ())
+    {
+      mk_winsym = true;
+      mk_nativesym = false;
+    }
+  
   if (mk_winsym && !win32_newpath.exists ()
       && (isdevice || !win32_newpath.fs_is_nfs ()))
     {
@@ -1530,6 +1536,27 @@ symlink_worker (const char *oldpath, con
       goto done;
     }
 
+  if (mk_nativesym)
+    {
+      win32_oldpath.check (oldpath, PC_SYM_NOFOLLOW, stat_suffixes);
+      DWORD dwFlags = win32_oldpath.isdir () ? SYMBOLIC_LINK_FLAG_DIRECTORY : 0;
+      if (isabspath (oldpath))
+        {
+          res = CreateSymbolicLink (win32_newpath.get_win32 (), win32_oldpath.get_win32 (), dwFlags) ? 0 : -1;
+        }
+      else
+        {
+          char *oldpath_trans = strdup (oldpath);
+          // Transform path separators
+          for (char *p = oldpath_trans; (p = strchr (p, '/')); p++)
+            *p = '\\';
+
+          res = CreateSymbolicLink (win32_newpath.get_win32 (), oldpath_trans, dwFlags) ? 0 : -1;
+          free (oldpath_trans);
+        }
+      goto done;
+    }
+    
   if (mk_winsym)
     {
       ITEMIDLIST *pidl = NULL;
Index: cygwin/syscalls.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
retrieving revision 1.604
diff -u -p -r1.604 syscalls.cc
--- cygwin/syscalls.cc	3 Dec 2011 23:55:21 -0000	1.604
+++ cygwin/syscalls.cc	4 Dec 2011 06:17:15 -0000
@@ -2923,7 +2923,7 @@ mknod_worker (const char *path, mode_t t
   char buf[sizeof (":\\00000000:00000000:00000000") + PATH_MAX];
   sprintf (buf, ":\\%x:%x:%x", major, minor,
 	   type | (mode & (S_IRWXU | S_IRWXG | S_IRWXO)));
-  return symlink_worker (buf, path, true, true);
+  return symlink_worker (buf, path, true, false, true);
 }
 
 extern "C" int
Index: cygwin/winsup.h
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/winsup.h,v
retrieving revision 1.240
diff -u -p -r1.240 winsup.h
--- cygwin/winsup.h	14 Nov 2011 01:29:49 -0000	1.240
+++ cygwin/winsup.h	4 Dec 2011 06:17:15 -0000
@@ -248,7 +248,7 @@ extern "C" void vklog (int priority, con
 extern "C" void klog (int priority, const char *message, ...);
 bool child_copy (HANDLE, bool, ...);
 
-int symlink_worker (const char *, const char *, bool, bool)
+int symlink_worker (const char *, const char *, bool, bool, bool)
   __attribute__ ((regparm (3)));
 
 class path_conv;

Re: Add support for creating native windows symlinks

[Andy Koppe]

On 4 December 2011 07:07, Russell Davis wrote:
> This was discussed before here:
> http://cygwin.com/ml/cygwin/2008-03/msg00277.html
>
> These were the reasons given for not using native symlinks to create
> cygwin symlinks, along with my responses:
>
> - By default, only administrators have the right to create native
>   symlinks.  Admins running with restricted permissions under UAC don't
>   have this right.
>
> This is true, however the feature can be made optional through the
> CYGWIN environment variable (just like winsymlinks). For users that
> can add the permission or disable UAC, the use of native symlinks is a
> huge step towards making cygwin more unified with the rest of Windows.
>
> - When creating a native symlink, you have to define if this symlink
>   points to a file or a directory.  This makes no sense given that
>   symlinks often are created before the target they point to.
>
> Also true. However, the type only matters for Windows' usage of the
> symlink -- cygwin already treats both the types the same. For example,
> if a native symlink of type `file` actually points to a directory, it
> will still work fine inside cygwin. It won't work for Win32 programs
> that try to access it, but that's still no worse than the status quo
> -- Win32 programs already can't use cygwin symlinks.
>
> Since cygwin already supports reading of native symlinks, I was able
> to add support for this with a fairly small change. Some edge cases
> probably still need to be handled (disabling for older versions of
> windows and unsupported file systems), but I wanted to get this out
> there for review. The patch is attached.

Those aren't all the issues with using native symlinks as Cygwin
symlinks. POSIX symlinks of course are supposed to point to POSIX
paths, whereas native links point to Windows paths, with the following
consequences:

- Native links can't point to special Cygwin paths such as /proc and
/dev, although I guess that could be fudged.
- If the meaning of the POSIX path changes due to Cygwin mount point
changes, native symlinks won't reflect that and point to the wrong
thing.
- Native relative links can't cross drive boundaries, whereas relative
POSIX paths can reach the whole filesystem.

I think the better approach here is to have an ln-like utility that
creates Windows symlinks, as proposed by Daniel Colascione at
http://cygwin.com/ml/cygwin/2011-04/msg00059.html. Perhaps it could be
added to cygutils if it was knocked into appropriate shape. (The main
advantage over using Windows facilities, in particular cmd.exe's
mklink builtin, would be an ln-like interface and Cygwin charset
support.)

Andy

Re: Add support for creating native windows symlinks

[Russell Davis]

Hi Andy, thanks for the response.

> - Native links can't point to special Cygwin paths such as /proc and
> /dev, although I guess that could be fudged.

They can, they just won't work when non-cygwin apps try to use them
(perhaps what you're eluding to with the fudging). This is no worse
than the status quo with cygwin's non-native symlinks -- non-cygwin
apps can't follow those either. Verified as working with the original
patch.

> - If the meaning of the POSIX path changes due to Cygwin mount point
> changes, native symlinks won't reflect that and point to the wrong
> thing.

Good point, but surely this must already be the case with
shortcut-style symlinks (via CYGWIN=winsymlinks) as well? For a lot of
users I think this will never be an issue, for the rest it can be
documented as a known limitation.

> - Native relative links can't cross drive boundaries, whereas relative
> POSIX paths can reach the whole filesystem.

As with the first point, they can still do this, it just won't work
outside of cygwin.

In summary, this approach does have limitations, but I don't think any
of them are worse than the status quo. In addition, it would be a an
optional feature that would be disabled by default, just like
winsymlinks. Seems like a net benefit for users who understand it and
want to use it.


-Russell

Re: Add support for creating native windows symlinks

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 3691 bytes --]

On 12/4/11 12:17 PM, Andy Koppe wrote:
> On 4 December 2011 07:07, Russell Davis wrote:
>> This was discussed before here:
>> http://cygwin.com/ml/cygwin/2008-03/msg00277.html
>>
>> These were the reasons given for not using native symlinks to create
>> cygwin symlinks, along with my responses:
>>
>> - By default, only administrators have the right to create native
>>   symlinks.  Admins running with restricted permissions under UAC don't
>>   have this right.
>>
>> This is true, however the feature can be made optional through the
>> CYGWIN environment variable (just like winsymlinks). For users that
>> can add the permission or disable UAC, the use of native symlinks is a
>> huge step towards making cygwin more unified with the rest of Windows.
>>
>> - When creating a native symlink, you have to define if this symlink
>>   points to a file or a directory.  This makes no sense given that
>>   symlinks often are created before the target they point to.
>>
>> Also true. However, the type only matters for Windows' usage of the
>> symlink -- cygwin already treats both the types the same. For example,
>> if a native symlink of type `file` actually points to a directory, it
>> will still work fine inside cygwin. It won't work for Win32 programs
>> that try to access it, but that's still no worse than the status quo
>> -- Win32 programs already can't use cygwin symlinks.
>>
>> Since cygwin already supports reading of native symlinks, I was able
>> to add support for this with a fairly small change. Some edge cases
>> probably still need to be handled (disabling for older versions of
>> windows and unsupported file systems), but I wanted to get this out
>> there for review. The patch is attached.
> 
> Those aren't all the issues with using native symlinks as Cygwin
> symlinks. POSIX symlinks of course are supposed to point to POSIX
> paths, whereas native links point to Windows paths, with the following
> consequences:
> 
> - Native links can't point to special Cygwin paths such as /proc and
> /dev, although I guess that could be fudged.
> - If the meaning of the POSIX path changes due to Cygwin mount point
> changes, native symlinks won't reflect that and point to the wrong
> thing.
> - Native relative links can't cross drive boundaries, whereas relative
> POSIX paths can reach the whole filesystem.

In addition, Windows systems ignore symlinks to remote volumes by default,
ostensibly for security reasons. (This behavior can be changed by using the
in-box fsutil program.) I agree that using Windows symlinks to implement
symlink(2) is a bad idea.

> I think the better approach here is to have an ln-like utility that
> creates Windows symlinks, as proposed by Daniel Colascione at
> http://cygwin.com/ml/cygwin/2011-04/msg00059.html. Perhaps it could be
> added to cygutils if it was knocked into appropriate shape. (The main
> advantage over using Windows facilities, in particular cmd.exe's
> mklink builtin, would be an ln-like interface and Cygwin charset
> support.)

I've sent an updated version of the program to the main Cygwin mailing list. Is
the new version suitable?

By the way: could we add an option to _not_ support shortcut-style symlinks?
("neverwinsymlinks"?) To support winsymlinks-created symlinks, we open an extra
two files for every open(2) call, even when winsymlinks isn't present in CYGWIN.

That is, when we open /foo/bar/qux, we actually try opening /foo/bar/qux.lnk,
/foo/bar/qux, /foo/bar/qux.exe.lnk, and /foo/bar/qux.exe. Skipping two of these
would benefit performance, and *I* know for certain that on my system, I don't
use .lnk-style links.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Add support for creating native windows symlinks

[Corinna Vinschen]

On Dec  3 23:07, Russell Davis wrote:
> This was discussed before here:
> http://cygwin.com/ml/cygwin/2008-03/msg00277.html

See also http://sourceware.org/ml/cygwin/2009-10/msg00756.html

> These were the reasons given for not using native symlinks to create
> cygwin symlinks, along with my responses:
> 
> - By default, only administrators have the right to create native
>   symlinks.  Admins running with restricted permissions under UAC don't
>   have this right.
> 
> This is true, however the feature can be made optional through the
> CYGWIN environment variable (just like winsymlinks). For users that
> can add the permission or disable UAC, the use of native symlinks is a
> huge step towards making cygwin more unified with the rest of Windows.
> 
> - When creating a native symlink, you have to define if this symlink
>   points to a file or a directory.  This makes no sense given that
>   symlinks often are created before the target they point to.
> 
> Also true. However, the type only matters for Windows' usage of the
> symlink -- cygwin already treats both the types the same. For example,
> if a native symlink of type `file` actually points to a directory, it
> will still work fine inside cygwin. It won't work for Win32 programs
> that try to access it, but that's still no worse than the status quo
> -- Win32 programs already can't use cygwin symlinks.
> 
> Since cygwin already supports reading of native symlinks, I was able
> to add support for this with a fairly small change. Some edge cases
> probably still need to be handled (disabling for older versions of
> windows and unsupported file systems), but I wanted to get this out
> there for review. The patch is attached.

I'm not at all convinced that it makes sense to add support to create
native symlinks to Cygwin.  Since Vista was in beta stage I'm
experimenting on and off with them, since every few months I had such a
great idea how to implement POSIX symlinks using them, but in the end it
was all futile since Windows is so uncooperative.  And I didn't restrict
my experiments to using the CreateSymbolicLink function.  I still have
my test binary which wrote the symlinks directly, using the
FSCTL_SET_REPARSE_POINT ioctl call.  The restrictions of these native
symlinks are rather disappointing and disqualify them for a POSIX
environment(*).

There's also a problem with your patch.  It uses the CreateSymbolicLinkA
function.  Given that the multibyte win32 path in path_conv is given in
the current Cygwin multibyte charset, you can't do that.  Rather you
would have to use the wide char path returned by get_wide_win32_path.
And then it doesn't make sense to call CreateSymbolicLinkW since we
already have the native path handy and could call NtFsControlFile with
the FSCTL_SET_REPARSE_POINT ioctl directly.

Last but not least, we can't include non-trivial patches from you,
unless you sign the copyright assignment form.  See
http://cygwin.com/contrib.html, the "Before you get started" section.
An awkward but necessary requirement.


Corinna


(*) As a side note, I'm really puzzled about that.  They could have
    been such a nice addition to create sylinks in SUA, but the way
    they have been implemented even disqualifies them for usage in SUA.
    That's probably the reason SUA still creates its own symlink style
    to date.

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

Re: Add support for creating native windows symlinks

[Corinna Vinschen]

On Dec  4 13:07, Russell Davis wrote:
> Hi Andy, thanks for the response.
> 
> > - Native links can't point to special Cygwin paths such as /proc and
> > /dev, although I guess that could be fudged.
> 
> They can, they just won't work when non-cygwin apps try to use them
> (perhaps what you're eluding to with the fudging). This is no worse
> than the status quo with cygwin's non-native symlinks -- non-cygwin
> apps can't follow those either. Verified as working with the original
> patch.
> 
> > - If the meaning of the POSIX path changes due to Cygwin mount point
> > changes, native symlinks won't reflect that and point to the wrong
> > thing.
> 
> Good point, but surely this must already be the case with
> shortcut-style symlinks (via CYGWIN=winsymlinks) as well?

No.  The Cygwin shortcut-style symlinks contain the POSIX path as well
and Cygwin only utilizes the POSIX path.  See symlink_info::check_shortcut.


Corinna

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

Re: Add support for creating native windows symlinks

[Russell Davis]

> See also http://sourceware.org/ml/cygwin/2009-10/msg00756.html

Quoting from that link:

- Due to the way they are used in the Win32 API, there's no way to
  use them with POSIX paths *and* Win32 paths for interoperability.
  So why bother?

Yeah, this is rather unfortunate. I agree, since we can't store both
the Win32 AND the POSIX path, it's not possible for native symlinks to
function correctly both inside and outside of cygwin for all possible
cases. But the point I've been making is this -- if we can make them
work within cygwin for 100% of cases, and outside of cygwin for 90% of
cases, what's the problem? It's still better than the existing cygwin
symlinks which work 100% within cygwin and 0% outside of cygwin.

If the "works within cygwin for 100% of cases" is in question, let's
discuss that. (Any path that might be problematic as a Win32 path can
just be stored as a POSIX path, and would fall into the bucket of
"works inside cygwin but not outside").


> There's also a problem with your patch.

Thanks, I figured it would need some clean up and polish. I wanted to
get it out there as a starting point.


Thanks,
Russell

Re: Add support for creating native windows symlinks

[Russell Davis]

Can someone respond to this? If there's a problem with my suggested
approach I'd like to know what it is. Let me know if clarification is
needed. Thanks...

On Mon, Dec 5, 2011 at 11:17 AM, Russell Davis <russell.davis@gmail.com> wrote:
>
> > See also http://sourceware.org/ml/cygwin/2009-10/msg00756.html
>
> Quoting from that link:
>
> - Due to the way they are used in the Win32 API, there's no way to
>  use them with POSIX paths *and* Win32 paths for interoperability.
>  So why bother?
>
> Yeah, this is rather unfortunate. I agree, since we can't store both
> the Win32 AND the POSIX path, it's not possible for native symlinks to
> function correctly both inside and outside of cygwin for all possible
> cases. But the point I've been making is this -- if we can make them
> work within cygwin for 100% of cases, and outside of cygwin for 90% of
> cases, what's the problem? It's still better than the existing cygwin
> symlinks which work 100% within cygwin and 0% outside of cygwin.
>
> If the "works within cygwin for 100% of cases" is in question, let's
> discuss that. (Any path that might be problematic as a Win32 path can
> just be stored as a POSIX path, and would fall into the bucket of
> "works inside cygwin but not outside").
>
>
> > There's also a problem with your patch.
>
> Thanks, I figured it would need some clean up and polish. I wanted to
> get it out there as a starting point.
>
>
> Thanks,
> Russell

Re: Add support for creating native windows symlinks

[Corinna Vinschen]

On Dec 18 12:16, Russell Davis wrote:
> Can someone respond to this? If there's a problem with my suggested
> approach I'd like to know what it is. Let me know if clarification is
> needed. Thanks...

I don't think it's the right approach to let Cygwin create symlinks
which are only partially usable in the POSIX environment, even if only
after explicitely enabling them(*).  I agree with Andy and Daniel that
using a special tool like Daniel's winln for this purpose is the way to
go.


Corinna

(*) Actually I wished desparately I hadn't included the "winsymlink"
    setting.  It seemed such a good idea at the time, but the extra
    code necessary to support .lnk symlinks transparently is a big
    mess.

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

Re: Add support for creating native windows symlinks

[Russell Davis]

> I don't think it's the right approach to let Cygwin create symlinks
> which are only partially usable in the POSIX environment...

Huh? I think you're not fully understanding my suggested approach. As
I pointed out in my previous message, it should be 100%, fully usable
in the POSIX environment. Again: any path that might be problematic as
a Win32 path can just be stored as a POSIX path, and would fall into
the bucket of "works inside cygwin but not outside".

Re: Add support for creating native windows symlinks

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On 12/19/11 11:31 AM, Russell Davis wrote:
>> I don't think it's the right approach to let Cygwin create symlinks
>> which are only partially usable in the POSIX environment...
> 
> Huh? I think you're not fully understanding my suggested approach. As
> I pointed out in my previous message, it should be 100%, fully usable
> in the POSIX environment. Again: any path that might be problematic as
> a Win32 path can just be stored as a POSIX path, and would fall into
> the bucket of "works inside cygwin but not outside".
> 

That's only true until the mount table changes.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Add support for creating native windows symlinks

[Russell Davis]

> That's only true until the mount table changes.

Can you elaborate on that? If I create a symlink pointing to /mnt/foo
(and store the actual POSIX path /mnt/foo in the symlink), and the
mount table changes, what's the problem?

Re: Add support for creating native windows symlinks

[Corinna Vinschen]

On Dec 19 11:31, Russell Davis wrote:
> > I don't think it's the right approach to let Cygwin create symlinks
> > which are only partially usable in the POSIX environment...
> 
> Huh? I think you're not fully understanding my suggested approach. As
> I pointed out in my previous message, it should be 100%, fully usable
> in the POSIX environment. Again: any path that might be problematic as
> a Win32 path can just be stored as a POSIX path, and would fall into
> the bucket of "works inside cygwin but not outside".

How are you going to check the difference?

Btw., you can write the Win32 and the POSIX path into the reparse point
since the reparse data buffer contains two strings, the so called
SubstituteName and the so called PrintName.  SubstituteName is the
native NT path which is used internally to resolve the path, the
PrintName is used by CMD or Explorer for printing purposes.  If you put
the POSIX path into PrintName, CMD shows the POSIX path and Explorer
shows an empty string as target location.  Of course you can't do that
using the CreateSymbolicLink call.

However, how do you make sure that the file vs directory flag is set
correctly, given that the file or directory doesn't have to exist at the
time the symlink gets created?  Neither CMD nor Explorer handle this
situation gracefully.

How do you handle the fact that remote symlinks only work if certain
settings are made (fsutil)?  And how do you handle the situation that
native symlinks don't work on pre-Vista machines, which also makes them
unsuitable for remote shares?  Some symlinks on a share are created this
way and some symlinks are created that way and depending on the machine
from where you try to access them they are usable or not.

As I said, I experimented a lot with native symlinks in the past and one
way or the other they don't quite work as expected.  I'm not overly keen
to support writing them.  The hassle with the required
SE_CREATE_SYMBOLIC_LINK_NAME privilege, the extra hassle that they don't
work on remote drives without explicitely enabling them via fsutil, the
fact that remote pre-Vista machines don't get them transparently
translated at all, the nonsense with the file/directory flag...  I'm
quite content to read them in Cygwin on a local drive but otherwise
leave them alone.  for those who really want them there are tools out
there to create them, but in these cases the tool provider has to take
the support burden.


Corinna

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

Re: Add support for creating native windows symlinks

[Russell Davis]

Sigh... I've already addressed all of these ponts (there are simple
ways to handle to all of them). I'm done fighting this battle.

Happy Festivus!


>> Huh? I think you're not fully understanding my suggested approach. As
>> I pointed out in my previous message, it should be 100%, fully usable
>> in the POSIX environment. Again: any path that might be problematic as
>> a Win32 path can just be stored as a POSIX path, and would fall into
>> the bucket of "works inside cygwin but not outside".
>
> How are you going to check the difference?
>
> Btw., you can write the Win32 and the POSIX path into the reparse point
> since the reparse data buffer contains two strings, the so called
> SubstituteName and the so called PrintName.  SubstituteName is the
> native NT path which is used internally to resolve the path, the
> PrintName is used by CMD or Explorer for printing purposes.  If you put
> the POSIX path into PrintName, CMD shows the POSIX path and Explorer
> shows an empty string as target location.  Of course you can't do that
> using the CreateSymbolicLink call.
>
> However, how do you make sure that the file vs directory flag is set
> correctly, given that the file or directory doesn't have to exist at the
> time the symlink gets created?  Neither CMD nor Explorer handle this
> situation gracefully.
>
> How do you handle the fact that remote symlinks only work if certain
> settings are made (fsutil)?  And how do you handle the situation that
> native symlinks don't work on pre-Vista machines, which also makes them
> unsuitable for remote shares?  Some symlinks on a share are created this
> way and some symlinks are created that way and depending on the machine
> from where you try to access them they are usable or not.
>
> As I said, I experimented a lot with native symlinks in the past and one
> way or the other they don't quite work as expected.  I'm not overly keen
> to support writing them.  The hassle with the required
> SE_CREATE_SYMBOLIC_LINK_NAME privilege, the extra hassle that they don't
> work on remote drives without explicitely enabling them via fsutil, the
> fact that remote pre-Vista machines don't get them transparently
> translated at all, the nonsense with the file/directory flag...  I'm
> quite content to read them in Cygwin on a local drive but otherwise
> leave them alone.  for those who really want them there are tools out
> there to create them, but in these cases the tool provider has to take
> the support burden.
>
>
> Corinna

Re: Add support for creating native windows symlinks

[Christopher Faylor]

On Fri, Dec 23, 2011 at 01:38:07PM -0800, Russell Davis wrote:
>Sigh... I've already addressed all of these ponts (there are simple
>ways to handle to all of them). I'm done fighting this battle.

Actually, I don't think you did answer all of them.  But, regardless, to
summarize, what you were proposing was adding functionality to Cygwin
which would allow you to create and manipulate "native" symlinks on
systems >= Vista which would could only be guaranteed to work reliably
within Cygwin itself.  It would be possible, if you know the rules, to
create symlinks which would be usuable outside of Cygwin also.

Since the only benefit that I can see over the current symlinks is that
they could be usable under Windows, I, personally, don't think the
drawbacks to using this approach is worth the cost of further
complicating Cygwin's already labyrinthian path handling capabilities
especially since it seems like adding support to Cygwin would guarantee
end-user confusion.

cgf