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
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
> 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.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk