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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 21, 2008, 19:09 UTC
Message-ID: <alpine.LFD.1.10.0804211203460.2779@woody.linux-foundation.org>
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.

Show 7 quoted lines

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

Show 7 quoted lines

> 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