Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
