improve / offer better alternative to realpath

[StefanKarpinski]

The realpath function is kind of a problem child. See #34132 and JuliaLang/Pkg.jl#1547 for cases where it is necessary to jump through all sorts of hoops to make sure that realpath, instead of just crashing and burning, does something reasonable. In both cases there were already previously some kind of protections for various failure cases around these usages of realpath. On the other hand, realpath is in libc and we don't really want to go around changing what it does willy nilly. There seem to be two kinds of issues that are encountered:

1. The full path doesn't exist, in which case the libc function fails. In this case, what people actually want is an answer to the question: if I created this path, what would its realpath be? In other words, resolve symlinks in the path prefix that does exist, normalize out . and .. entries and leave the non-existent part of the path alone.

2. On some filesystems (e.g. network drives), it's possible that the user can read contents later in the path but not earlier in the path, but realpath requires being able to read each prefix of the full path in order to do the normalization. It might be better in such cases to just take whatever is given at face value and move on, even if that isn't guaranteed to give a fully globally "realized" path. This would be far less all or nothing than the current workaround of just trying realpath and giving up and returning the original path as is if anything goes wrong.

Arguably, both of these are non-breaking changes, since code that previously worked will continue to work, but I do worry about making changes to what is generally expected to be a system function. These changes sound very expensive, but realpath is already so expensive that I doubt that it matters.

[fredrikekre]

Duplicate of #33956 ?

[StefanKarpinski]

Really? How is it a duplicate of that more specific issue that I'm clearly aware of?

[00vareladavid]

+100 Having some working normalizer would be invaluable when navigating the edge case minefield that is filesystem path handling.

As one example: I wanted to find the "base" directory from user input but I found that basename("foo/bar") != basename("foo/bar/"). I'm still not sure what the practical difference is. normpath seemed promising, but normpath("foo/bar") != normpath("foo/bar/"). realpath does what I want, but it is plagued by all the issues described above.

I think it would make more sense to include this functionality in normpath instead of realpath. It seems to fit the name better and (as Stefan explains) realpath already has a predefined meaning.

[vtjnash]

In other words, resolve symlinks in the path prefix that does exist, normalize out . and .. entries and leave the non-existent part of the path alone.

This is somewhat contradictory: on posix . and .. are just symlinks that don't exist

Having some working normalizer

What you want sounds more like (the existing) samepath function (for example, Base.Filesystem.samefile(".", pwd()) === true)