Message-ID: <4D9CA535.9000206@gmail.com>
Date: Wed, 06 Apr 2011 10:39:01 -0700
From: Daniel Colascione <dan DOT colascione AT gmail DOT com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Utility: winln, a drop-in replacement for ln(1)
References: <4D9A2A5B DOT 7060502 AT gmail DOT com> <BANLkTimqik9dE2rN-k=e3-OJ_a0PZRH59Q AT mail DOT gmail DOT com>
In-Reply-To: <BANLkTimqik9dE2rN-k=e3-OJ_a0PZRH59Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On 4/6/2011 1:26 AM, Andy Koppe wrote:
> On 4 April 2011 21:30, Daniel Colascione wrote:
>> Attached is a small program that behaves very similarly to ln(1), but that
>> works with Windows hard and symbolic links instead of Cygwin ones.
>>   Successful use of this program requires Vista or newer, a user with
>> SeCreateSymbolicLinkPrivilege, and a symlink evaluation policy that allows
>> the kind of symbolic link you'd like to create.  If these conditions are
>> met, however, this program becomes useful because it can create symbolic
>> links that work equally well for Cygwin and non-Cygwin programs.  Because
>> its argument handling is practically identical to that of coreutils ln,
>> winln can be used via a simple shell alias (or PATH prefixing, if you're
>> feeling bold).
>
> Very nice, and much better than faffing about with 'cmd /c mklink' and cygpath.

Thanks for taking a look.

> - Coretools ln also creates native Windows hard links, via Cygwin's
> link() function.

Yes, but I wanted winln to match ln's behavior, and that requires using 
hard links by default.  So yes, there's a bit of overlap.

> - Cygwin link() directly invokes the NT API, which I think avoids some
> filename restrictions at the Win32 level.

That's a good point.  I haven't run into these issues myself, but maybe 
the next version of winln can also use the native API.

> - winln doesn't have the .exe magic where links to .exes automatically
> have .exe appended if it's not already present.

Good point. Thanks.

> - Native symbolic links require administrator privileges and aren't
> available at all before Vista.

They don't require administrator privilege per se: just 
SeCreateSymbolicLinkPrivilege, which can be granted to normal user 
accounts via local security policy.  The easiest way to grant 
SeCreateSymbolicLinkPrivilege is to start gpedit.msc, go down to 
"Windows Settings"->"Security Settings"->"Local Policies"->"User Rights 
Assignment", then find "Create symbolic links" and add whatever users 
and groups you want[1].

> - 'cmd /c mklink /j' allows to create directory junction points
> without administrator privileges. Junction points are more or less
> equivalent with symbolic links, and the 'linkd' utility from the
> Windows Reource Kit Tools even allows to create them on XP. Hence it
> might be useful for winln to fall back to junction points when
> symbolic links aren't available.

That's a possibility, but I'm worried about that issue triggering bugs 
in other programs --- IIRC, many programs would treat the junction point 
as a normal directory and get into unbreakable loops, or recursively 
delete the pointed-to tree.  Maybe that's fixed now.

> - Native symbolic links obviously point at Windows paths, which means
> they end up pointing at the wrong thing if the meaning of their
> original POSIX path changes, in particular due to changing mount
> points or Cygwin symlinks in the original path.

Right. That's an explicit tradeoff we have to make.  I run with an 
identity mapping from / to C:\, however, so the issue never comes up in 
practice.

> - 'winln' always creates a link to the absolute Windows path when
> given a relative path.

No it doesn't.  Relative links work fine --- cmd /c dir reports them as 
relative, anyway.

> This means the link will point at the wrong
> thing if it's moved about. I don't know whether native relative links
> are possible.

They are possible, and at least in my testing, they work fine.  A 
relative symbolic link should be created whenever cygpath -w returns a 
relative path.

> (Some of these points rule out the use of native symbolic links as
> Cygwin symbolic links.)

And that's a shame.  Windows symbolic links are tantalizingly close to 
POSIX links, but not quite there.


[1] I wonder why Windows uses these security rights things instead of 
just using a normal group for each privilege under "User Rights 
Assignment", each with a well-known SID.  That'd have reduced the number 
of moving parts in the system.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple