[lttng-dev] [lttng-tools PATCH 0/5] Follow up to the realpath(3) for unexistent paths
David Goulet
dgoulet at efficios.com
Fri Nov 15 10:45:39 EST 2013
On 14 Nov (19:58:30), Raphaël Beamonte wrote:
> David,
>
> Following the discussions we had on IRC with Mathieu and the last
> mail exchange, here is a series of patch that should answer to our
> enquiries.
>
> The first two patches are linked to the utils_expand_path unit test
> and correct its behavior and the expected results (some input was
> at first considered invalid, but during our discussions it was
> mentionned that it should be considered valid).
>
> The next three ones introduce a new utils_partial_realpath that,
> as its name says it, allows to partially resolve a real path for
> a given path. This function is then used in utils_expand_path to
> resolve the paths, and the utils_resolve_relative function is
> removed as it is not necessary anymore in this new "setup".
>
> Waiting for your comments,
Hey Raph,
I've created a symlink directory maze here to test theses patches and
everything seems to work fine but I got one wrong use case. I'll print my maze
here so you can recreate:
/tmp/test $
.
└── a
├── b
│ ├── c
│ │ └── g -> ../../../
│ ├── f -> ../e/
│ ├── h -> ../g/
│ └── k -> c/g/
├── d -> b/c/
├── e
└── g -> d/
10 directories, 0 files
$ lttng create -o /tmp/test/a/g/../l/..
Session auto-20131115-103416 created.
Traces will be written in /tmp/test/a/b/l/..
Note the "/.." at the end. Relative or not, same output. Seems like "./" and
"../" *after* an unexisting path fails to parse. In this case, I would throw in
an error since there is simply no way of knowing that "l/" is going to point
to.
What I'm going to do here is to merge those 5 patches and wait for fix(es) that
we'll merge in the RC cycle. The feature is there just not perfect :). 2.4-rc1
is coming up this morning btw.
Thanks!
David
> Raphaël
>
> Raphaël Beamonte (5):
> Tests: add a check in test_utils_expand_path to avoid segfault if
> result is NULL
> Tests: move invalid tests in test_utils_expand_path that should be
> valid
> Introduce a new utils_partial_realpath function
> Change the utils_expand_path function to use utils_partial_realpath
> Remove the utils_resolve_relative function that is not useful anymore
>
> .gitignore | 1 -
> src/common/utils.c | 256 ++++++++++++++++++------------
> src/common/utils.h | 3 +-
> tests/unit/Makefile.am | 7 +-
> tests/unit/test_utils_expand_path.c | 7 +-
> tests/unit/test_utils_resolve_relative.c | 98 ------------
> tests/unit_tests | 1 -
> 7 files changed, 158 insertions(+), 215 deletions(-)
> delete mode 100644 tests/unit/test_utils_resolve_relative.c
>
> --
> 1.7.10.4
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: Digital signature
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20131115/898d8720/attachment.pgp>
More information about the lttng-dev
mailing list