Re: [boost] [filesystem] Request for comments on proposed relative() function

Subject: Re: [boost] [filesystem] Request for comments on proposed relative() function
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2014-05-16 05:17:22

On Fri, May 16, 2014 at 11:41 AM, Gavin Lambert <gavinl_at_[hidden]>wrote:

> ...
> Again, I don't think relative(*, some-relative-path) is a sensible
> operation.
>
> Besides, relative(absolute(path1, X), absolute(path2, X)) ==
> relative(absolute(path1, Y), absolute(path2, Y)) for any X & Y when both
> paths are non-rooted relative; any cwd injection will cancel out.
>

Absolute is not relevant to the definition. I feel we lost each other. To
make it constructive, do you agree with my definition:

    relative(x,y) returns a path z (unique up to equivalence), if exists,
such that y / z = x (up to equivalence)

? Here I'm using the abstract definitions of / and equivalence, which may
vary depending on the effect you want to achieve.

> And finally, the working dir of each drive is not actually filesystem
> state.  It's environment state, separately owned by each process (albeit
> inherited from its parent).  So you're not actually accessing the
> filesystem when you get the CWD.

You still access some state external to the given paths. This is what I
want to avoid.

True, but there isn't a good answer to that unless you can determine what
> the cwd of c: is (or just assume it's the root, which is a bad idea
> especially for console programs).  Which means this case depends on
> "filesystem state" -- though actually environment. ... (Which is apparently
> what Boost.Filesystem does, but only when using system_complete() instead
> of absolute().  I'm not sure why these have different behaviour;
> system_complete() seems more sensible.)

This is exactly what I am telling! You either want to combine paths, this
is what / is for (in my definition), or complete them with some current
system-dependent state, which is what system_complete() does. (Sometimes
you want to do both, in that order.) To get an absolute path on Windows
(using today's boost.fs), one has to call system_complete(), *not*
absolute() (!!!), because the later does not capture platform semantics
correctly.

>
>  This all sounds good, but working with paths relative to an *unknown* base
>> is useful. Think of some project directory that tries to be relocatable.
>>
>
> I don't see how that would be a problem.  It can use
> absolute(path-in-config-file, path-of-project) to obtain the "real"
> location of some resource while running, and then write it back using
> relative(real-location, path-of-project).  You're free to move the project
> and its resources around between runs and the links will be preserved as
> long as the internal structure is maintained.
>

Don't you think that resolving two paths w.r.t. the same base, just in
order to get the difference between them, shows that relative of two
relative paths make sense on its own? If you read carefully the definitions
in my OP, the relative() I described has exactly this property: for
relative paths it works as-if assuming both have all possible bases
prepended (same base for both).

An unknown base is only something that exists in storage.  To actually
> accomplish anything useful, you need to know what the actual base is. (It's
> usually not sensible to manipulate the path by itself -- you have to do the
> same manipulation [eg. renaming] to the actual resource or you'll break the
> link.)

How about getting a relative path between two files in a project? I.e. one
pointing to another.

-- 
Yakov