On Fri, Oct 7, 2011 at 2:43 PM, Lars Viklund
In boost 1.47.0 filesystem v3, boost::filesystem::absolute only appends
relative path to base path. It should also remove "./" from relative
On Fri, Oct 07, 2011 at 09:52:32AM +0530, Sachin Garg wrote: the 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#a...
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