Re: [PATCH v3 1/4] real_path: resolve symlinks by hand
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 12, 2016, 23:32 UTC
- Message-ID
- <xmqqk2b47mgz.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20161212225006.GB193413@google.com>
Brandon Williams <bmwill@google.com> writes:
Show 14 quoted lines
> 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.
Show 16 quoted lines
>> > + /* 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.