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? That would conceptually be what an OS that refuses to follow symlinks at path walk time (because it doesn't support symlinks as such) would return: the symlink component would not be a directory, so it's as if you were trying to use a path a/b/c/d/e where "a/b" isn't even a directory. In fact, even on Linux, ENOTDIR is what an lstat() would return if "b" had been turned from a directory into a regular file - which is conceptually (for git) _exactly_ the same as "b" being a symlink. No? Linus -- 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
