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

Brandon Williams [off-list ref] writes:

On 12/12, Junio C Hamano wrote:
...

quoted

E.g. for input path "foo/bar/", the above loop runs zero times and
then ...

quoted

+	/* 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.

quoted

quoted

+	/* 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.