Re: [Boost-users] [filesystem] filesystem::absolute() doesn't work with ../relative_path or ./relative_path

Subject: Re: [Boost-users] [filesystem] filesystem::absolute() doesn't work with ../relative_path or ./relative_path
From: Sachin Garg (schngrg_at_[hidden])
Date: 2011-10-07 08:02:47

On Fri, Oct 7, 2011 at 2:43 PM, Lars Viklund <zao_at_[hidden]> wrote:

> On Fri, Oct 07, 2011 at 09:52:32AM +0530, Sachin Garg wrote:
> > In boost 1.47.0 filesystem v3, boost::filesystem::absolute only appends
> the
> > relative path to base path. It should also remove "./" from relative
> paths
> > and "backtrack" on base path if relative path contains "../../" etc.
>
> That is outside the scope of the function.
>
> In order to properly handle `..`, it would have to hit the filesystem
> to find out the information needed to canonicalize the path, as you
> cannot naïvely assume that a `..` is equivalent to removing parts of the
> path. Thanks to symlinks and hardlinks, you can find yourself in a
> completely different area of the filesystems. Resolving paths is
> something that functions that need to resolve paths do, not a simple
> mechanical absolute().
>
> If the function did this (which it shouldn't), it would be completely
> unusable if the path does not represent assets on the local machine,
> assets rooted somewhere else, assets in a virtual filesystem, and so on.
>
> It would also have a lot more error cases, like not being able to
> traverse the directory hierarchy.
>
> All in all, the behaviour is a feature, not a bug.
>
> In any way, the documentation explains exactly how the resulting path is
> composed:
>
> http://www.boost.org/doc/libs/1_47_0/libs/filesystem/v3/doc/reference.html#absolute
>
>
I do understand that it is complicated to resolve paths but at the same time
I feel that the main motivation to have boost::filesystem is that it takes
care of most such complications under a cross-platform API. It is not a
string manipulation library and is aware of underlying filesystem's
properties.

When both the base and relative paths are valid and together point to a
valid location, the result of absolute shouldn't be an invalid path like
d:\base\path\.\..\..\file (while using such a path on windows cmd or bash
shell works, it fails when such a path is passed to APIs under windows or
linux).

SG