Re: [PATCH 01/02/RFC] implement a stat cache

Linus Torvalds [off-list ref] writes:

On Mon, 21 Apr 2008, Junio C Hamano wrote:

quoted

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.

quoted

                /*
                 * 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:

quoted

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.