Re: [PATCH 01/02/RFC] implement a stat cache
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 21, 2008, 20:06 UTC
- Message-ID
- <7vprsj9dmc.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <alpine.LFD.1.10.0804211203460.2779@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 31 quoted lines
> 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.