On Fri, Oct 7, 2011 at 2:43 PM, Lars Viklund <zao@acc.umu.se> 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).