Re: [GSoC][PATCH v4 2/7] clone: better handle symlinked files at .git/objects/

From: Thomas Gummerer <t.gummerer@gmail.com>
Date: Mar 29, 2019, 20:05 UTC
Message-ID: <20190329200517.GO32487@hank.intra.tgummerer.com>
In-Reply-To: <CAHd-oW78Cwhq8sFFjOX4c6kS8JsEUUd_RGgheJhdN6MLAr+G2Q@mail.gmail.com>

On 03/29, Matheus Tavares Bernardino wrote:

Show 18 quoted lines

> On Thu, Mar 28, 2019 at 7:10 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > I notice that we are currently not using 'linkat()' anywhere else in
> > our codebase.  It looks like it has been introduced in POSIX.1-2008,
> > which sounds fairly recent by git's standards.  So I wonder if this is
> > really supported on all platforms that git is being built on.
> >
> > I also wonder what would need to be done on Windows if we were to
> > introduce this.  I see we define the 'link()' function in
> > 'compat/mingw.c' for that currently, so I guess something similar
> > would be needed for 'linkat()'.  I added Dscho to Cc for Windows
> > expertise.
> 
> Ok, what if instead of using linkat() we use 'realpath(const char
> *path, char *resolved_path)', which will resolve any symlinks at
> 'path' and store the canonical path at 'resolved_path'? Then, we can
> still keep using link() but now, with the certainty that all platforms
> will have a consistent behaviour? (also, realpath() is POSIX.1-2001)
> Would that be a better idea?

Yeah, I think that is a good idea. Note that 'realpath()' itself is not used anywhere in our codebase either, but there is 'strbuf_realpath()', that from reading the function documentation does exactly what 'realpath()' would do. So using 'strbuf_realpath()' would probably be the right thing to do here.