Utility: winln, a drop-in replacement for ln(1)

[Daniel Colascione]

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