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

Subject: Re: [boost] [filesystem] Request for comments on proposed relative() function
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-05-16 04:41:24

On 16/05/2014 19:21, quoth Yakov Galka:
>> 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).
>
> It is unexpected for me -- when I'm dealing with paths I don't want to
> access the filesystem at all, unless I specifically say that.

But you *are* specifically saying that by not supplying an absolute path 
as your base path.

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.

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.

>> absolute("c:foo", "c:/bar") == "c:/bar/foo"
>>
>> This requires that case.
>
> And absolute("c:foo", "d:/bar") == "c:/bar/foo"... It does not make sense.

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.

(And it's not arbitrary state -- it's state that's set either earlier in 
your own process or by your parent process possibly in preparation to 
execute you.  So it's not unreasonable to depend on it.)

But it's not correct to treat this as an invalid case either.  Imagine a 
console program that is trying to translate a user-supplied argument 
(the first parameter) into an absolute path based on its CWD (the second 
parameter).  Both the program and the user should expect, by convention, 
that the previously-used-WD of C: should be used in the expansion.  As in:

   cd /d c:\baz
   cd /d d:\bar
   zap quux c:foo

The parameters are well defined and should expand to d:\bar\quux and 
c:\baz\foo respectively.  (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 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.

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.)