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
