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

[Andy Koppe <andy dot koppe at gmail dot com>]

On 6 April 2011 18:39, Daniel Colascione wrote:
> 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.

Yeah, it was mostly for the benefit of others to point out that Cygwin
hard links already are native anyway. It certainly makes sense to have
them in winln too for the sake of symmetry with ln, but you could just
implement them as link() instead of doing it the hard way.

>> - 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].

Btw, any idea why they were restricted in that way?

>> - '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.

Don't directory symbolic links have the same issue? And are you
talking about Cygwin programs or native ones? FWIW, Cygwin treats
junction points as symbolic links.

>> - 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.

Yep.

> I run with an identity mapping from / to C:\

What do you mean by that?

>> - '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.

Sorry, you're right, must have confused myself in testing.

Here's a real issue though: you're using MultiByteToWideChar with the
thread codepage to translate relative paths, which is rather unlikely
to be the same as the Cygwin filesystem charset (which defaults to
UTF-8), resulting in stuff like this:

$ ./winln -s foo bÃr
$ ls -l
...
lrwxrwxrwx  1 Andy None      3 Apr  6 20:35 bÃÂr -> foo

This problem can be addressed by using mbstowcs() to do the
conversion, after first selecting the correct charset with
setlocale(LC_CTYPE, ""). Even with that, however, you're still missing
out on certain tricks in Cygwin filename conversion, in particular the
replacement of characters such as ':' that are disallowed in Windows
filenames with codepoints in the Unicode private range.

Therefore, if at all possible, you should use cygwin_create_path() for
all paths. What's the reason for treating relative paths specially?

Finally, what's with the bug referred to here?

	/* Work around a bug that causes Cygwin to resolve the path if it
           ends in a native symbolic link.

	   Note that this bug makes symlinks-to-symlinks point to the ultimate
	   target, and there's no good way around that.

Regards,
Andy

--
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