Answers below

Le 09/08/2017 à 15:30, David Macek a écrit :
On 9. 8. 2017 14:59, Vincent Belaïche wrote:
I must admit that I don't know the difference between a cygwin-y symlink and a NTFS native symlinks. And I just presume that MS implementation of symlinks is a superset of NTFS native symlinks.

Microsoft's symlinks *are* NTFS native symlinks.

The URL that you give is interesting in this that it explains that MS symlinks can be created by non-administrators provided that they are given some corresponding priviledge.

Correct. The privilege requirement IIRC can also be removed as of some version of Windows 10.

to my knowledge SVN MSW clients can't be configured to follow symlinks at the moment (sigh) whatever the user priviledges

As you mentioned via the link to MSDN, "MSW" programs don't care too much about symlinks. Following the should just work. Of course, that's with NTFS symlinks, not Cygwin-y ones.

On 9. 8. 2017 15:13, Vincent Belaïche wrote:

So there are actually two issues with MSYS2 pseudo-symlinks :

- non ASCII letters (I don't care)

Nice catch, I created a ticket<> for this issue.

- this does not work : cd gnats; ln -s ../* .

Yes, because you're trying to create a recursive symlink. A symlink would work, but since MSYS2 emulates symlinks by copying, it enters a potentially infinite loop of creating further subdirectories that's broken only due to some path length limitation. I don't know if there's anything to be done about it.

The symlink emulation could keep track of all elements already copied once, and every time it is inspecting a new element to be copied, it would cancel the copy if the element has already been copied. This would break this infinite loop stuff (otherwise it breaks only when the path length exceed the maximum allowed).

L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Msys2-users mailing list

Reply via email to