Add support for creating native windows symlinks

Corinna Vinschen corinna-cygwin@cygwin.com
Mon Dec 5 10:17:00 GMT 2011


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



More information about the Cygwin-patches mailing list