Re: Add support for creating native windows symlinks

[Daniel Colascione <dan dot colascione at gmail dot com>]

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: signature.asc
Description: OpenPGP digital signature