Thread overview
[Issue 9530] std.path should have a function for getting the canonical path to a file or directory
Jul 05, 2017
Vladimir Panteleev
Jul 05, 2017
Jonathan M Davis
Jul 05, 2017
Vladimir Panteleev
Dec 17, 2022
Iain Buclaw
July 05, 2017
https://issues.dlang.org/show_bug.cgi?id=9530

Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dlang-bugzilla@thecybershad
                   |                            |ow.net

--- Comment #2 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
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.

--
July 05, 2017
https://issues.dlang.org/show_bug.cgi?id=9530

--- Comment #3 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
(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.

--
July 05, 2017
https://issues.dlang.org/show_bug.cgi?id=9530

--- Comment #4 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
(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.

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=9530

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4

--
December 01
https://issues.dlang.org/show_bug.cgi?id=9530

--- Comment #5 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
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

--