This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]