From: Linus Torvalds Date: Mon, 21 Apr 2008 19:09:43 GMT Subject: Re: [PATCH 01/02/RFC] implement a stat cache Message-ID: In-Reply-To: <7v3apfawry.fsf@gitster.siamese.dyndns.org> 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