Boost logo

Boost :

Subject: Re: [boost] [filesystem] Request for comments on proposed relative() function
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-05-15 20:53:37

On 16/05/2014 00:44, quoth Yakov Galka:
> One problem with boost filesystem is the lack of theoretical foundation.

There kind of is one if you look at the Definitions section at
  I'm not completely convinced that the implemented methods actually
obey this though, nor that they are necessarily wrong in not doing so. :)

> Operations (examples are for Windows, because it is less trivial than
> Unix):
> * concatenation -- already defined:
> * "a" / "b" = "a/b"
> * "c:" / "d" = "c:d"
> * "/a/b" / "c:" = "c:"
> * "a" / "../b" = "a/../b"
> * "d:/a" / "/b" = "d:/b"
> * is_absolute(x) iff there exists f such that for all g, g / x = f.
> * is_absolute("d:/xyz") = true
> * is_absolute("/abc") = false
> * is_absolute("c:") = true or false, depending on whether we
> include the environment states into the filesystem node quantification.
> * relative(x, y) = z s.t. y / z is equivalent to x. (not always exists)
> * relative("a/b", "a") = "b"
> * relative("c:/a/b", "c:") = "/a/b"
> * relative("c:/a/b", "c:/") = "c:/"
> * relative("c:a/b", "c:/") = NaP
> * relative(x, "") = x

Agree with most of those, except:
   relative("c:/a/b", "c:/") = "a/b"
   relative("c:a/b", "d:/") = "c:a/b"
   relative("c:a/b", "c:/") = "a/b"
(Case 2 because that's still a valid relative path from d:/ base; case 3
because it's implied that c:/ is the cwd of c:, and given that the path
is equivalent to case 1. Though I accept that this third case may be
borderline; alternatively it should return the same as case 2.)

Also I'm dubious whether allowing the base-path of relative() to be
itself relative is useful in any way. In particular the case
relative(absolute-path, relative-path) seems nonsensical; at best it
should probably return the unmodified absolute-path.

Though I suppose for consistency with absolute/canonical, relative()
could use absolute(base) as its base internally, which would produce
reasonable results (albeit somewhat dependent on filesystem state -- but
that's not unexpected when dealing with relative paths).

> Note that on Windows, AFAIK but I may be mistaken, eval-equivalence and
> equivalence are the same, because ".." are resolved syntactically by
> Win32 API before any reparse points etc. kick-in. One can think of
> eval-parent ".." meaning 'go back' whereas the Unix parent ".." behave
> as a regular subdirectory. One may still wish to distinguish between
> equivalence and eval-equivalence on Windows.

I'm not sure how the Linux filesystem in general behaves, but the shell
typically appears to do the same thing -- cd into a symlinked folder
followed by "cd .." gets you back to your original folder, not the
parent of the symlink target.

> absolute(p,base) illogical
> --------------------------
> The case when p.has_root_name() && !p.has_root_directory() makes no
> sense. I remember that it was once left unspecified. Don't know why it
> got defined now.

absolute("c:foo", "c:/bar") == "c:/bar/foo"

This requires that case.

> * canonical() -- a better name would be resolve(), cause what it
> ultimately does is resolving symlinks? Naming it realpath() is also an
> option.

It also appears to currently be the only function that resolves ".."
path fragments. I would prefer if there were a function that does this
lexically, without hitting the filesystem or requiring that the path
actually exist.

(Perhaps system_complete()? Hard to tell from the docs, as it defines
its behaviour in terms of a function that does not exist.)

> Rationale: by the definitions section, paths are abstract entities
> detached from the filesystem. Asking for relative(x,y) or x/y are
> legitimate questions on their own, even if the paths do not exist at the
> specific point in time and space. Even when x and y are relative to a
> yet-unknown base. Making them depend on the current filesystem state is
> error prone.

I don't think anyone ever suggested relative() should require that the
path exist. But I don't think that it's unreasonable for it to react to
the current directory of each drive -- that's the purpose of relative
paths. (And if you want it to be relative to some other folder, you
should specify which one explicitly as an absolute path, and then there
is no dependency on the filesystem.)

> RFC and thanks for your attention,
> Yakov Galka

I think most of the points you brought up here aren't really on-topic in
this particular thread, and would have been better made in a separate
thread (or by writing your own alternative implementation). I doubt
it's likely that grand sweeping changes to an existing accepted library
would get anywhere. But that doesn't mean you couldn't submit an
alternative intended to supersede it; that's happened in the past.

But hey, I'm not a maintainer, so what do I know. :)

Boost list run by bdawes at, gregod at, cpdaniel at, john at