[PATCH] setup: translate symlinks in filename when using absolute paths

[PATCH] setup: translate symlinks in filename when using absolute paths

[Carlo Marcelo Arenas Belon]

otherwise, comparison to validate against work tree will fail when
the path includes a symlink and the name passed is not canonical.

Signed-off-by: Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>
---
 setup.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/setup.c b/setup.c
index 91887a4..e7c0d4d 100644
--- a/setup.c
+++ b/setup.c
@@ -7,10 +7,13 @@ static int inside_work_tree = -1;
 char *prefix_path(const char *prefix, int len, const char *path)
 {
 	const char *orig = path;
-	char *sanitized = xmalloc(len + strlen(path) + 1);
-	if (is_absolute_path(orig))
-		strcpy(sanitized, path);
-	else {
+	char *sanitized;
+	if (is_absolute_path(orig)) {
+		const char *temp = make_absolute_path(path);
+		sanitized = xmalloc(len + strlen(temp) + 1);
+		strcpy(sanitized, temp);
+	} else {
+		sanitized = xmalloc(len + strlen(path) + 1);
 		if (len)
 			memcpy(sanitized, prefix, len);
 		strcpy(sanitized + len, path);
-- 
1.7.3.4.626.g73e7b.dirty

Re: [PATCH] setup: translate symlinks in filename when using absolute paths

[Junio C Hamano]

Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe> writes:

> otherwise, comparison to validate against work tree will fail when
> the path includes a symlink and the name passed is not canonical.
>
> Signed-off-by: Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>

I take that "path" and "name passed" refer to the same thing (i.e. "path"
parameter) in the above.

I think you are trying to handle the case where:

 - you give "/home/carenas/one" from the command line;
 - $PWD is "/home/carenas"; and
 - "/home/carenas" is a symlink to "/net/host/home/carenas"

and the scan-from-the-beginning-of-string check done between
"/home/carenas/one" and the return value of get_git_work_tree() which
presumably is "/net/host/home/carenas" disagrees.  I wonder if a more
correct solution might be to help get_git_work_tree() to match the notion
of where the repository and its worktree are to the idea of where the user
thinks they are, i.e. not "/net/host/home/carenas" but "/home/carenas", a
bit better?

That would involve tweaking make_absolute_path() I guess?

Note that your patch is the right thing to do either case, i.e. with or
without such a change to make_absolute_path(), as the function is used to
set up the return value from get_git_work_tree().  Anything we compare
with it should have passed make_absolute_path() at least once.

Nguyễn?

> ---
>  setup.c |   11 +++++++----
>  1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/setup.c b/setup.c
> index 91887a4..e7c0d4d 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -7,10 +7,13 @@ static int inside_work_tree = -1;
>  char *prefix_path(const char *prefix, int len, const char *path)
>  {
>  	const char *orig = path;
> -	char *sanitized = xmalloc(len + strlen(path) + 1);
> -	if (is_absolute_path(orig))
> -		strcpy(sanitized, path);
> -	else {
> +	char *sanitized;
> +	if (is_absolute_path(orig)) {
> +		const char *temp = make_absolute_path(path);
> +		sanitized = xmalloc(len + strlen(temp) + 1);
> +		strcpy(sanitized, temp);
> +	} else {
> +		sanitized = xmalloc(len + strlen(path) + 1);
>  		if (len)
>  			memcpy(sanitized, prefix, len);
>  		strcpy(sanitized + len, path);
> -- 
> 1.7.3.4.626.g73e7b.dirty

Re: [PATCH] setup: translate symlinks in filename when using absolute paths

[Carlo Marcelo Arenas Belon]

On Tue, Dec 28, 2010 at 11:47:07AM -0800, Junio C Hamano wrote:
> Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe> writes:
> 
> > otherwise, comparison to validate against work tree will fail when
> > the path includes a symlink and the name passed is not canonical.
> >
> > Signed-off-by: Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>
> 
> I take that "path" and "name passed" refer to the same thing (i.e. "path"
> parameter) in the above.

yes, and sorry for the cryptic description; you detailed below though this
is triggered by the fact that when using an absolute path filename as a
parameter detection for worktree is failing because it was normalized
through make_absolute_path.

> I think you are trying to handle the case where:
> 
>  - you give "/home/carenas/one" from the command line;
>  - $PWD is "/home/carenas"; and
>  - "/home/carenas" is a symlink to "/net/host/home/carenas"

this will be a valid  scenario, but the issue (with a different use case)
was reported in (which I missed to refer to when running git send-email):

  http://thread.gmane.org/gmane.comp.version-control.git/164212

> and the scan-from-the-beginning-of-string check done between
> "/home/carenas/one" and the return value of get_git_work_tree() which
> presumably is "/net/host/home/carenas" disagrees.  I wonder if a more
> correct solution might be to help get_git_work_tree() to match the notion
> of where the repository and its worktree are to the idea of where the user
> thinks they are, i.e. not "/net/host/home/carenas" but "/home/carenas", a
> bit better?

are you suggesting symlinks would be left untouched at least during
resolution for work_dir?, why is even necesary to resolve the links for
other users of that function?

Carlo

Re: [PATCH] setup: translate symlinks in filename when using absolute paths

[Nguyen Thai Ngoc Duy]

2010/12/29 Junio C Hamano <gitster@pobox.com>:
> Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe> writes:
>
>> otherwise, comparison to validate against work tree will fail when
>> the path includes a symlink and the name passed is not canonical.
>>
>> Signed-off-by: Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>
>
> I take that "path" and "name passed" refer to the same thing (i.e. "path"
> parameter) in the above.
>
> I think you are trying to handle the case where:
>
>  - you give "/home/carenas/one" from the command line;
>  - $PWD is "/home/carenas"; and
>  - "/home/carenas" is a symlink to "/net/host/home/carenas"
>
> and the scan-from-the-beginning-of-string check done between
> "/home/carenas/one" and the return value of get_git_work_tree() which
> presumably is "/net/host/home/carenas" disagrees.  I wonder if a more
> correct solution might be to help get_git_work_tree() to match the notion
> of where the repository and its worktree are to the idea of where the user
> thinks they are, i.e. not "/net/host/home/carenas" but "/home/carenas", a
> bit better?

I tend to agree. Will cause less surprises (such as this one).

> That would involve tweaking make_absolute_path() I guess?

Hm.. can we avoid converting work_tree to absolute path unless people
explicitly set it (via --work-tree and GIT_WORK_TREE)? Basically
worktree will be relative to cwd. Usually it's just ".". When people
run commands outside worktree, it's the relative "cwd/to/worktree".
I'm wondering if we can just avoid the use of make_absolute_path()
completely in get_git_work_tree()..

> Note that your patch is the right thing to do either case, i.e. with or
> without such a change to make_absolute_path(), as the function is used to
> set up the return value from get_git_work_tree().  Anything we compare
> with it should have passed make_absolute_path() at least once.

Yes, I think that should that be done inside normalize_path_copy(),
not prefix_path().

>>  setup.c |   11 +++++++----
>>  1 files changed, 7 insertions(+), 4 deletions(-)

Also Carlo, tests should be good for illustration and regression
purposes. I know you described in detail in another mail. But mails
tend to get lost.
-- 
Duy