Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [lttng-dev] [lttng-tools PATCH 1/4] Introduce a new	utils_resolve_relative function
Date: Thu, 14 Nov 2013 14:19:21 +0000 (UTC)	[thread overview]
Message-ID: <254665384.67131.1384438761175.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <1384320878-28808-2-git-send-email-raphael.beamonte@gmail.com>

Some comments...

----- Original Message -----
> From: "Rapha?l Beamonte" <raphael.beamonte@gmail.com>
> To: dgoulet at efficios.com
> Cc: "Rapha?l Beamonte" <raphael.beamonte at gmail.com>, lttng-dev at lists.lttng.org
> Sent: Wednesday, November 13, 2013 12:34:35 AM
> Subject: [lttng-dev] [lttng-tools PATCH 1/4] Introduce a new	utils_resolve_relative function
> 
> This function aims to resolve relative path such as './' and
> '../' in the middle of a path string. This allows to use paths
> such as '~/../test' that are received as '/home/x/../test' for
> instance.
> 
> Signed-off-by: Rapha?l Beamonte <raphael.beamonte at gmail.com>
> ---
>  src/common/utils.c |   68
>  ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  src/common/utils.h |    1 +
>  2 files changed, 69 insertions(+)
> 
> diff --git a/src/common/utils.c b/src/common/utils.c
> index da4c036..4ccf36a 100644
> --- a/src/common/utils.c
> +++ b/src/common/utils.c
> @@ -36,6 +36,74 @@
>  #include "defaults.h"
>  
>  /*
> + * Resolve the './' and '../' strings in the middle of a path using
> + * our very own way to do it, so that it works even if the directory
> + * does not exist

We should document that this returns allocated memory which needs to be freed by the caller.

Also, we should clearly state that the only reason why we implement this is that realpath() only works on existing paths, which does not cover our use-case of having to resolve partially unexisting paths.

> + */
> +LTTNG_HIDDEN
> +char *utils_resolve_relative(const char *path)
> +{
> +	char *next, *previous, *slash, *start_path, *absolute_path = NULL;
> +
> +	/* Safety net */
> +	if (path == NULL) {
> +		goto error;
> +	}
> +
> +	/* Allocate memory for the absolute path */
> +	absolute_path = zmalloc(PATH_MAX);
> +	if (absolute_path == NULL) {
> +		PERROR("zmalloc expand path");
> +		goto error;
> +	}
> +
> +	/* Copy the path in the absolute path */
> +	strncpy(absolute_path, path, PATH_MAX);
> +
> +	/* As long as we find '/./' in the path string */
> +	while ((next = strstr(absolute_path, "/./"))) {
> +
> +		/* We prepare the start_path not containing it */
> +		start_path = strndup(absolute_path, next - absolute_path);
> +
> +		/* And we concatenate it with the part after this string */
> +		snprintf(absolute_path, PATH_MAX, "%s%s", start_path, next + 2);
> +
> +		free(start_path);
> +	}
> +
> +	/* As long as we find '/../' in the path string */
> +	while ((next = strstr(absolute_path, "/../"))) {
> +		/* If the path starts with '/../', there's a problem */
> +		if (next == absolute_path) {
> +			ERR("%s: Path cannot be resolved", path);
> +			goto error;
> +		}
> +
> +		/* We find the last level of directory */
> +		previous = absolute_path;
> +		while ((slash = strpbrk(previous + 1, "/")) && slash != next) {
> +			previous = slash;
> +		}
> +
> +		/* Then we prepare the start_path not containing it */
> +		start_path = strndup(absolute_path, previous - absolute_path);
> +
> +		/* And we concatenate it with the part after the '/../' */
> +		snprintf(absolute_path, PATH_MAX, "%s%s", start_path, next + 3);
> +
> +		free(start_path);
> +	}

I might be missing something, but how can this work on paths like this ?

"./a/../b/./c/../d/./e" ?

At first glance, it looks like the only cases that work correctly are those in the test case, but there are various variants that won't.

One possible alternative approach to all this path mangling would be to use realpath() on sections of paths (using / as separator, from the start of path), until realpath() fails to lookup the final paths. Maybe then could we simply append the paths as is without resolving. Users would have to know that they should not put "." or ".." in the unexisting part of their paths. Thoughts ?

Thanks,

Mathieu

> +
> +	return absolute_path;
> +
> +error:
> +	free(absolute_path);
> +	return NULL;
> +}
> +
> +
> +/*
>   * Return the realpath(3) of the path even if the last directory token does
>   not
>   * exist. For example, with /tmp/test1/test2, if test2/ does not exist but
>   the
>   * /tmp/test1 does, the real path is returned. In normal time, realpath(3)
> diff --git a/src/common/utils.h b/src/common/utils.h
> index 52f2798..c56942f 100644
> --- a/src/common/utils.h
> +++ b/src/common/utils.h
> @@ -26,6 +26,7 @@
>  #define MEBI_LOG2 20
>  #define GIBI_LOG2 30
>  
> +char *utils_resolve_relative(const char *path);
>  char *utils_expand_path(const char *path);
>  int utils_create_pipe(int *dst);
>  int utils_create_pipe_cloexec(int *dst);
> --
> 1.7.10.4
> 
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com



  reply	other threads:[~2013-11-14 14:19 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-08  4:32 [lttng-dev] [lttng-tools PATCH 0/2] utils_expand_path as realpath(3) for non-existing directories Raphaël Beamonte
2013-11-08  4:32 ` [lttng-dev] [lttng-tools PATCH 1/2] Introduce a new utils_resolve_relative function Raphaël Beamonte
2013-11-12 19:51   ` David Goulet
2013-11-13  5:34     ` [lttng-dev] [lttng-tools PATCH 0/4] Update to utils_expand_path as realpath(3) for non-existing directories Raphaël Beamonte
2013-11-13  5:34       ` [lttng-dev] [lttng-tools PATCH 1/4] Introduce a new utils_resolve_relative function Raphaël Beamonte
2013-11-14 14:19         ` Mathieu Desnoyers [this message]
2013-11-14 17:07           ` Raphaël Beamonte
2013-11-13  5:34       ` [lttng-dev] [lttng-tools PATCH 2/4] Tests: Add test_utils_resolve_relative to unit tests Raphaël Beamonte
2013-11-13  5:34       ` [lttng-dev] [lttng-tools PATCH 3/4] Correct the behavior of the utils_expand_path function Raphaël Beamonte
2013-11-14  2:44         ` Mathieu Desnoyers
2013-11-14  3:27           ` Raphaël Beamonte
2013-11-14 13:46             ` Mathieu Desnoyers
2013-11-14 14:10         ` Mathieu Desnoyers
2013-11-14 16:00           ` Raphaël Beamonte
2013-11-14 16:14             ` Mathieu Desnoyers
2013-11-15  0:58               ` [lttng-dev] [lttng-tools PATCH 0/5] Follow up to the realpath(3) for unexistent paths Raphaël Beamonte
2013-11-15  0:58                 ` [lttng-dev] [lttng-tools PATCH 1/5] Tests: add a check in test_utils_expand_path to avoid segfault if result is NULL Raphaël Beamonte
2013-11-15  0:58                 ` [lttng-dev] [lttng-tools PATCH 2/5] Tests: move invalid tests in test_utils_expand_path that should be valid Raphaël Beamonte
2013-11-15  0:58                 ` [lttng-dev] [lttng-tools PATCH 3/5] Introduce a new utils_partial_realpath function Raphaël Beamonte
2013-11-15  0:58                 ` [lttng-dev] [lttng-tools PATCH 4/5] Change the utils_expand_path function to use utils_partial_realpath Raphaël Beamonte
2013-11-15  0:58                 ` [lttng-dev] [lttng-tools PATCH 5/5] Remove the utils_resolve_relative function that is not useful anymore Raphaël Beamonte
2013-11-15 15:45                 ` [lttng-dev] [lttng-tools PATCH 0/5] Follow up to the realpath(3) for unexistent paths David Goulet
2013-11-23 22:32                   ` [lttng-dev] [lttng-tools PATCH 0/5] utils_expand_path fix Raphaël Beamonte
2013-11-23 22:32                     ` [lttng-dev] [lttng-tools PATCH 1/5] Add missing copyright to utils.c Raphaël Beamonte
2013-11-23 22:32                     ` [lttng-dev] [lttng-tools PATCH 2/5] Fix: comment indentation Raphaël Beamonte
2013-11-23 22:32                     ` [lttng-dev] [lttng-tools PATCH 3/5] Fix: utils_expand_path now works for paths that ends with '/.' or '/..' Raphaël Beamonte
2013-11-23 22:32                     ` [lttng-dev] [lttng-tools PATCH 4/5] Tests: add symlink tests for test_utils_expand_path Raphaël Beamonte
2013-11-23 22:32                     ` [lttng-dev] [lttng-tools PATCH 5/5] Tests: add valid test cases to test_utils_expand_path Raphaël Beamonte
2013-11-25 15:51                     ` [lttng-dev] [lttng-tools PATCH 0/5] utils_expand_path fix David Goulet
2013-11-13  5:34       ` [lttng-dev] [lttng-tools PATCH 4/4] Tests: Add test_utils_expand_path to unit tests Raphaël Beamonte
2013-11-13 21:28       ` [lttng-dev] [lttng-tools PATCH 0/4] Update to utils_expand_path as realpath(3) for non-existing directories David Goulet
2013-11-08  4:32 ` [lttng-dev] [lttng-tools PATCH 2/2] Correct the behavior of the utils_expand_path function Raphaël Beamonte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=254665384.67131.1384438761175.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox