Re: [PATCH] Fix off by one error in prep_exclude.

[Shawn Bohrer <shawn.bohrer@gmail.com>]

On Sun, Jan 27, 2008 at 02:34:13PM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> but doesn't address the fact that we probably should remove files that 
> >> aren't a part of the repository at in the first place.
> >
> > I am sorry, but I cannot begin to see what this commit tries to 
> > accomplish.  Yes, sure, there is an off-by-one error, and your commit 
> > message says how that was fixed.  But I miss a description what usage it 
> > would affect, i.e. when this bug triggers.
> >
> > I imagine that you would be as lost as me, reading that commit message 6 
> > months from now, trying to understand why that change was made.
> 
> Likewise.  The message has somewhat to be desired...

Agreed I'll resend with a improved message.
 
> In "struct exclude_stack", prep_exclude() and excluded(), the
> convention for a path is to express the length of directory part
> including the trailing slash (e.g. "foo" and "bar/baz" will get
> baselen=0 and baselen=4 respectively).
> 
> The variable current and parameter baselen follow that
> convention in the codepath the patch touches.
> 
> 		else {
> 			cp = strchr(base + current + 1, '/');
> 			if (!cp)
> 				die("oops in prep_exclude");
> 			cp++;
> 		}
> 		stk->prev = dir->exclude_stack;
> 		stk->baselen = cp - base;
> 
> is about coming up with the next value for current (which is
> taken from stk->baselen) to dig one more level.
> 
> If base="foo/a/boo" and current=4 (i.e. we are looking at
> "foo/"), at the point, scanning from (base+current) as Shawn
> Bohrer's patch suggests means the scan begins at "a/boo" to find
> the next slash.  The existing code skips one letter ('a') and
> starts scanning from "/boo".
> 
> The only case this microoptimization makes difference is when an
> input is malformed and has double-slash (i.e. path component
> whose length is zero), like "foo//boo".

Good catch, I didn't think of this case but this indeed will cause
the same issue.
 
> Perhaps the "oops part of the issue Johannes found" had a caller
> that feeds such an incorrect input?

Nope the problem Johannes Sixt was having was that he mistakenly ran

git clean -n /*foo

Now that isn't what he meant to do, but I figured it might be possible
that someone has their whole filesystem in a git repository, or maybe
is using some sort of chroot on their repository.  Your malformed
paths guess is probably much more likely to occur.

--
Shawn