Re: [PATCH v3 1/4] real_path: resolve symlinks by hand

[Junio C Hamano <gitster@pobox.com>]

Brandon Williams <bmwill@google.com> writes:

> On 12/12, Junio C Hamano wrote:
> ...
>> E.g. for input path "foo/bar/", the above loop runs zero times and
>> then ...
>> 
>> > +	/* Skip sequences of multiple path-separators */
>> > +	while (offset < len && is_dir_sep(path->buf[len - 1]))
>> > +		len--;
>> 
>> ... the slash at the end is removed, leaving "foo/bar" in path.
>
> The way this is currently used I don't believe this scenario can happen
> (since input to this shouldn't have trailing slashes), but if others
> begin to use this function then yes, that is an implicit assumption.

OK.

>> > +	/* Iterate over the remaining path components */
>> > +	while (remaining.len > 0) {
>> > +		get_next_component(&next, &remaining);
>> > +
>> > +		if (next.len == 0) {
>> > +			continue; /* empty component */
>> > +		} else if (next.len == 1 && !strcmp(next.buf, ".")) {
>> > +			continue; /* '.' component */
>> > +		} else if (next.len == 2 && !strcmp(next.buf, "..")) {
>> > +			/* '..' component; strip the last path component */
>> > +			strip_last_component(&resolved);
>> 
>> Wouldn't this let "resolved" eventually run out of the path
>> components to strip for a malformed input e.g. "/a/../../b"?
>
> As I understand it, that path is correct and would resolve to "/b".

That is OK on the traditional UNIX end.  

I am not sure if we want to handle the "//host/share/$remaining" in
this codepath, though.  If we do, then this is still an issue (IIRC,
somebody explained that we do not want to step into //host/share/
part when seeing ".."---we'd at least need to leave a NEEDSWORK
comment so that interested parties can later take a look into it.