https://issues.dlang.org/show_bug.cgi?id=9530
--- Comment #4 from Vladimir Panteleev <[email protected]> --- (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. --
