Re: git clone doesn't work in symlink dir roots on Windows

[Fredrik Gustafsson]

On Sat, Aug 10, 2013 at 07:22:03PM +0300, Sedat Kapanoglu wrote:
> > git is a disk intense program, so this setup is not sane at all. With
> > that said I know that git on windows historically had problems with
> > working on smb-mounted shares (sometimes you're forced to have stupid
> > setups). I doubt that git really is the right tool for your work, since
>
> I reproduced the same problem in a regular symlink directory. Repro steps:
>
> mkdir actualdir
> mklink /d symdir actualdir
> cd symdir
> git init .
>
> fatal: Invalid symlink 'D:/gitto': Function not implemented
>
> Thanks,
>
> Sedat

Good, then we can determinate that this is a symlink error, it seams
that readlink() isn't implemented in the msysgit version of msysgit.

However msysgit should have a implementation of readlink() according to:
http://mingw.5.n7.nabble.com/Replacement-for-readlink-td30679.html

I've CC:ed the msysgit-maillist so that they can decide if this is
something they want to address in newer releases.

(In the git source code the readlink call in this abspath.c)

--
Med v�nliga h�lsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iv...@iveqy.com

[Erik Faye-Lund]

On Sat, Aug 10, 2013 at 6:34 PM, Fredrik Gustafsson <iv...@iveqy.com> wrote:
> On Sat, Aug 10, 2013 at 07:22:03PM +0300, Sedat Kapanoglu wrote:
>> > git is a disk intense program, so this setup is not sane at all. With
>> > that said I know that git on windows historically had problems with
>> > working on smb-mounted shares (sometimes you're forced to have stupid
>> > setups). I doubt that git really is the right tool for your work, since
>>
>> I reproduced the same problem in a regular symlink directory. Repro steps:
>>
>> mkdir actualdir
>> mklink /d symdir actualdir
>> cd symdir
>> git init .
>>
>> fatal: Invalid symlink 'D:/gitto': Function not implemented
>>
>> Thanks,
>>
>> Sedat
>
> Good, then we can determinate that this is a symlink error, it seams
> that readlink() isn't implemented in the msysgit version of msysgit.
>
> However msysgit should have a implementation of readlink() according to:
> http://mingw.5.n7.nabble.com/Replacement-for-readlink-td30679.html
>
> I've CC:ed the msysgit-maillist so that they can decide if this is
> something they want to address in newer releases.

No, we do not. (I won't be bothered to read *yet* another thread about
someone who thinks they know how symlinks should work on Windows, so
I'll assume it's the Cygwin-take... which is the most senseful IMO)
Symlinks in Cygwin are generally not compatible with native Windows
applications.

And Windows symlinks are not at all compatible with POSIX-symlinks. At all.

Whoever wants symlink support in Git for Windows have clearly not
considered how this would work (or more likely, break). It's an idea
built on misunderstanding and poor engineering-concepts.

There's no way we can support symlinks in a clean, Windows specific
way. So let's not even pretend it works.

That being said, we could probably error out in a more senseful way.
But if so,suggestions/patches welcome.

[Sedat Kapanoglu]

Thanks folks. So that this won't be fixed, I added a new Q&A to
MsysGit FAQ at https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions
, I appreciate if you can review and correct if needed. I hope it will
help avoiding further conversations about this matter.

Sedat

[Erik Faye-Lund]

Thanks, that's very helpful!

[Michael Geddes]

This type of functionality is directly supported by the work I've already done
on symlinks here: https://github.com/frogonwheels/git
(branches mrg/symlink-v* )

Even if we agree that symlinks only work to a limited degree, or that there
are definite limitations, and that the default should be that symlinks NOT be
supported within repositories, I'm not sure why people are against
incorporating what I've already implemented.. ok well I guess I do - it's
about time.

Firstly, at the least it means that symlinks like this example where they are
outside the repository are supported. Secondly it means that people who are
prepared to accept the limitations will be able to use (or at least clone)
repositories containing symlinks.

One of the big, painful limitations is that windoze symlinks need to be marked
as directories at the time of creation. The code I have implemented does it's
level best to create the correct type of NTFS symlink based on repository
information and falling back on filesystem information.

The argument about permissions is only partially valid, since that can be
granted as an individual permission to the user without permanent
administrator rights.

//.ichael G.

[MNGoldenEagle]

Aside from having to specify whether or not the symbolic link points to a file or directory, what are the limitations of symlinks?  I'm a bit curious, having used them myself but never encountering any significant issues with them.  I remember hearing at one point that Windows Vista could only create up to 31 links inside a directory, but I just checked on my Windows 7 machine and was able to generate over 600 links to a directory without a problem, so I'm guessing Windows 7 worked around this issue.

Jesse

--

--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msy...@googlegroups.com
To unsubscribe from this group, send email to
msysgit+u...@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Michael]

I really don't know Jesse,

The permissions issue keeps coming up, but to me it seems a non-issue as there is a CLI command to issue the appropriate permissions to a user.  The directory link being separate is a painful but known issue, and my solution should work in most every-day ways, as long as the symlinks aren't dangling within the repository tree itself.

We could possibly limit the types of NTFS symbolic links that would actually be embedded in a git database to relative links (or is that done already?).  I'm quite happy to have 'That type of NTFS symbolic link is not supported' as a valid solution to anything that is outside of simple symbolic links.

Currently the biggest thing holding symlinks back from being complete is lack of support in MSYS itself - which might be solved by using MSYS2.   I have worked around this in the tests by overriding various commands with shell functions that implement operations on symlinks via cmd.exe.  The only current exception to this is tar, which I can't do much about.

I've just rebased my symlink branch onto pt/tentative-1.8.4 and am chasing down test failures.

The tests like to make the symlinks before creating directories, or to create dangling symlinks, which doesn't help my cause - but am working through it.

//.

[MNGoldenEagle]

Michael,

Well, I know that you need administrative permission to create symbolic links on Windows (specified in the Local Security Policy under "Create symbolic links"), so if you're not running as an administrator, that's probably the issue.  The only way around it is to modify the security policy or have Git request admin privileges if it needs to use symlinks.

Jesse