Bug 9530 – std.path should have a function for getting the canonical path to a file or directory

Take this example from std.path.absolutePath: assert (absolutePath("../file", "/foo/bar") == "/foo/bar/../file"); Note the ../ in the path. absolutePath does note return the canonical path (which is what I would have expected it to do), but even if it's better for absolutePath to not return the canonical path, we still need a function which will do that, and I don't see one in std.path which does. So, I think that either absolutePath should be changed to return the canonical path (which presumably it has a good reason for not doing), or std.path needs a new function which does.

Okay, it looks like we already have buildNormalizedPath which does some of what needs to be done for canonicalizing a path (it gets rid of ., .., and / from a path), but it doesn't follow symlinks, so it doesn't actually get a canonical path (every file should have one and only one canonical path). So, this request isn't quite as critical as I was thinking that it was, but we do still need a function for returning the canonical path of a file or directory.

This is a request for a realpath wrapper in Phobos, then? FWIW, I would argue that almost everywhere I've seen a usage of realpath, it was unnecessary and often even harmful - mainly because I think historically libc did not provide an easy way to canonicalize a path without resolving symlinks. But that's probably not a good reason to not provide a D wrapper for a standard C function. I'm not sure what to do with Windows, as there is no equivalent for it in Windows libcs, and Windows implements symlinks (and reparse points in general) very differently.

(In reply to Vladimir Panteleev from comment #2) > Fmainly because I think historically libc did not provide an easy > way to canonicalize a path without resolving symlinks. Resolving the symlinks is kind of the point here, because the idea is to have a function that gives you a single path to a file when given different paths to it so that you can know that they're the same file. And if you don't resolve symlinks, you definitely can't do that. I'd never heard of realpath before, but looking at its man page, it looks like it does what I'm talking about. > I'm not sure what to do with Windows, as there is no equivalent for it in > Windows libcs, and Windows implements symlinks (and reparse points in > general) very differently. I really have no idea how Windows symlinks work. So, I have no idea how possible this sort of thing is with Windows symlinks, but the idea it least is to be able to take a path name and get a single, canonical path for it so that you can compare paths and have them be the same for the same file regardless of how that file was originally referred to. Windows may or may not make that possible.

(In reply to Jonathan M Davis from comment #3) > (In reply to Vladimir Panteleev from comment #2) > > Fmainly because I think historically libc did not provide an easy > > way to canonicalize a path without resolving symlinks. > > Resolving the symlinks is kind of the point here, because the idea is to > have a function that gives you a single path to a file when given different > paths to it so that you can know that they're the same file. And if you > don't resolve symlinks, you definitely can't do that. I think this is a vain quest, due to things such as hard links, binds, multiple mounts, subvolumes, network filesystems, various filesystem-specific shenanigans, and platform differences such as those on Windows. By itself, that requirement is meaningless without a context, and I suspect that in many cases, depending on the context, a better way to solve the problem exists. > I really have no idea how Windows symlinks work. So, I have no idea how > possible this sort of thing is with Windows symlinks, but the idea it least > is to be able to take a path name and get a single, canonical path for it so > that you can compare paths and have them be the same for the same file > regardless of how that file was originally referred to. Windows may or may > not make that possible. I think the same general issues with this idea apply to Windows. For instance, a volume can be mounted on a drive letter or inside a directory, and none is "more important" or "more canonical" than the other.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/phobos/issues/9952 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB