Linus Torvalds <torvalds@linux-foundation.org> writes:

quoted text
> On Mon, 21 Apr 2008, Junio C Hamano wrote:
>> 
>> Doesn't it become very tempting to replace lstat() calls we make to check
>> the status of a work tree path, with a function git_wtstat() that is:
>
> Yes.
>
> That looks like a very good abstraction.
>
>>                 /*
>>                  * As far as git is concerned, this does not exist in
>>                  * the work tree!
>>                  */
>>                 errno = ENOENT;
>>                 return -1;
>>         }
>
> Well, how about returning something else than "ENOENT" here? 
>
> As you point out, git doesn't actually think this is a "does not exist" 
> case, but something else that may require more work:
>
>> This unfortunately is not enough to hide the need for has_symlink calls
>> from outside callers.  When we check out a new path "a/b/c/d/e", for
>> example, if we naively checked if we creat(2) "a/b/c/d/e" (and otherwise
>> we try the equivalent of "mkdir -p"), we would be tricked by a symlink
>> "a/b" that points at some random place that has "c/d" subdirectory in it,
>> and we need to unlink "a/b" first, and the above git_wtstat() does not
>> really help such codepath.
>
> Maybe ENOTDIR would be a better error return?

Yeah, and we could return which component in the given path is the
offending one at the same time.

In the above example, we would say "No, a/b/c/d/e does not exist because
a/b is a symlink".  But would that be enough, I have to wonder.  lstat(2)
may have already said "There is no a/b/c/d/f" in the same example, but we
still need to know "a/b" is an unwanted symbolic link if the reason we are
asking that question is because we would want to check out "a/b/c/d/f".

So the answer need to be "a/b/c/d/f" (does not exist|exists in the work
tree), and it cannot exist because "a/b" is a symlink for such a caller.

But when we are trying to git-add, we simply do not care such
distinction.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html