[filesystem] Resolving a path ?
Hello, I'd like to know if there is in boost::filesystem a way to "resolve" a path. For instance, I have a path that is built from : "c:\foo1\foo2\..\bar1\bar2" And I'd like to obtain: "c:\foo1\bar1\bar2" Best regards, -- Loïc
On Fri, Jul 11, 2008 at 14:11, Loïc Joly <loic.actarus.joly@numericable.fr> wrote:
I'd like to know if there is in boost::filesystem a way to "resolve" a path. For instance, I have a path that is built from : "c:\foo1\foo2\..\bar1\bar2"
And I'd like to obtain: "c:\foo1\bar1\bar2"
As I recall, that used to be called canonize, but it seems to have disappeared. There are still references to it, though, such as "Move canonize() and normalize() to convenience.hpp?" in the do list, and "Symbolic links cause canonical and normal form of some paths to represent different files or directories. For example, given the directory hierarchy /a/b/c, with a symbolic link in /a named x pointing to b/c, then under POSIX Pathname Resolution rules a path of "/a/x/.." should resolve to "/a/b". If "/a/x/.." were first normalized to "/a", it would resolve incorrectly. (Case supplied by Walter Landry.)" in the design rationale. (It'd be nice to have to make uncomplete easy to write, too.)
Scott McMurray a écrit :
As I recall, that used to be called canonize, but it seems to have disappeared.
There are still references to it, though, such as "Move canonize() and normalize() to convenience.hpp?" in the do list, and "Symbolic links cause canonical and normal form of some paths to represent different files or directories. For example, given the directory hierarchy /a/b/c, with a symbolic link in /a named x pointing to b/c, then under POSIX Pathname Resolution rules a path of "/a/x/.." should resolve to "/a/b". If "/a/x/.." were first normalized to "/a", it would resolve incorrectly. (Case supplied by Walter Landry.)" in the design rationale.
So, if I understand correctly, there used to be a canonize() function, but since it provided wrong results for corner cases, it was removed. Is that so ? -- Loïc
On Tue, Jul 15, 2008 at 02:26, Loïc Joly <loic.actarus.joly@numericable.fr> wrote:
So, if I understand correctly, there used to be a canonize() function, but since it provided wrong results for corner cases, it was removed. Is that so ?
The notes for 1.31.0 mention the following: "Separation of canonical form and normalized form and a new path member function normalize(). This changes behavior, in that canonical form is now different, but eliminates a subtle bug when symbolic links to directories are present. " Which suggests that is *was* wrong, but got fixed, and the old behaviour was moved into normalize. So I have no idea why it's no longer provided. Actually, it brings up a more critical issue, in that it seems there's no way to "dereference" a symlink... ~ Scott
Loïc Joly wrote:
Scott McMurray a écrit :
As I recall, that used to be called canonize, but it seems to have disappeared.
There are still references to it, though, such as "Move canonize() and normalize() to convenience.hpp?" in the do list, and "Symbolic links cause canonical and normal form of some paths to represent different files or directories. For example, given the directory hierarchy /a/b/c, with a symbolic link in /a named x pointing to b/c, then under POSIX Pathname Resolution rules a path of "/a/x/.." should resolve to "/a/b". If "/a/x/.." were first normalized to "/a", it would resolve incorrectly. (Case supplied by Walter Landry.)" in the design rationale.
So, if I understand correctly, there used to be a canonize() function, but since it provided wrong results for corner cases, it was removed. Is that so ?
It has been awhile, but I think that is correct. The canonize() function is actually still supplied but is deprecated. --Beman
participants (4)
-
Beman Dawes -
John Femiani -
Loïc Joly -
Scott McMurray