This is the mail archive of the
mailing list for the Cygwin project.
Re: Utility: winln, a drop-in replacement for ln(1)
- From: Andy Koppe <andy dot koppe at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 6 Apr 2011 09:26:07 +0100
- Subject: Re: Utility: winln, a drop-in replacement for ln(1)
- References: <4D9A2A5B.firstname.lastname@example.org>
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.
A few points of note:
- Coretools ln also creates native Windows hard links, via Cygwin's
- Cygwin link() directly invokes the NT API, which I think avoids some
filename restrictions at the Win32 level.
- winln doesn't have the .exe magic where links to .exes automatically
have .exe appended if it's not already present.
- Native symbolic links require administrator privileges and aren't
available at all before Vista.
- '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.
- 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.
- 'winln' always creates a link to the absolute Windows path when
given a relative path. This means the link will point at the wrong
thing if it's moved about. I don't know whether native relative links
(Some of these points rule out the use of native symbolic links as
Cygwin symbolic links.)
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple