Tracking Issue for `std::path::absolute`

[ChrisDenton]

View all comments

Feature gate: #![feature(absolute_path)]

This is a tracking issue for std::path::absolute for making relative paths absolute without touching the filesystem. It is a drop-in replacement for std::fs::canonicalize.

Public API

let absolute = std::path::absolute("foo/./bar")?;

Steps / History

• Implementation: std::path::absolute #91673
• Final comment period (FCP)
• Stabilization PR: Stabilize std::path::absolute #124335

Unresolved Questions

• on Windows this is currently implemented using GetFullPathNameW, which isn't quite a "pure" function (in some special cases, e.g. D:file.txt, it can use hidden environment variables, set by cmd.exe, to resolve the path's root).
• Should we recommend using absolute(a.join(b)), where a is an alternative current directory to using std::env::current_dir?
• Is the avoidance of stripping .. actually the right call? It does seem consistent with the POSIX docs, but may not be the most intuitive behavior (particularly given that Windows doesn't do that).
  • I think making the path absolute is inherently a platform-specific function. It can only really work according to the rules of the platform.

[ChrisDenton]

Ok, so cards on the table. My personal motivation for this function is to expose the Windows function GetFullPathNameW (or something similar) into the standard library in a way that can be used cross-platform. This is already used by the standard library for making verbatim paths (absolute paths that aren't limited by MAX_PATH). I've also heard from Linux users who want a way to make absolute paths that won't break on Windows. Previous related discussions include these internals thread where I explore other possibilities:

• Path::to_lexical_absolute
• Proposal: std::path::resolve

I'd like to address the unresolved issues of not resolving .. on *nix: it was felt that resolving this is undesirable as it would change the meaning of the path. Whereas on Windows it does not. This is a fundamental difference between POSIX and Windows. On Windows, .. is resolved lexically (aka without reference to the filesystem) whereas on POSIX systems it's essentially a symlink that can take you anywhere in the filesystem. It's not possible to resolve this dissonance so maybe we shouldn't hide it.

[ChrisDenton]

Should we prepend the current directory, or skip that step? The user can typically join with the current directory afterwards.

I feel this is mistaken. On Windows, when you pass a path to File::open or other fs operation, there is a fair amount of parsing done to get the "real" absolute path which is then passed to the kernel. It is often desirable to know exactly what path is actually being used to avoid surprises.

Here are some examples of the potential differences between using absolute and Path::join. I'm using cmd.exe which initially sets the current directory to C:\Users\Chris. I then change the current directory to D:\Chris\rust.

Input	std::path::absolute	current_dir()?.join
aux	\\.\aux	D:\Chris\rust\aux
C:file.txt	C:\Users\Chris\file.txt	C:file.txt
folder.\file... ..	D:\Chris\rust\folder\file	D:\Chris\rust\folder.\file.. ..

The idea of absolute is that it gives you the path the kernel will see so there are no surprises. Some of the Windows behaviour (in particular the legacy ones) can be very unintuitive. The absolute function avoids having to know much of the weirdness involved with user paths because it "knows" how to parse it the same way the OS does.

[golddranks]

whereas on POSIX systems it's essentially a symlink that can take you anywhere in the filesystem.

Could you elaborate on that? I get that /foo/a and /bar/a could point to the same directory a if, for example /bar/a is a symlink; do you mean that stripping the .. in /bar/a/.. is required to take you to the "physical" parent of the directory, /foo, thus requiring a filesystem access to resolve?

[ChrisDenton]

Yes. sorry I worded that badly. The absolute function doesn't use the file system to resolve paths so it can't know which directory .. should resolve to. Instead, canonicalize must be used to properly resolve such paths. It's the same reason why Path::components normalizes . but not ...

[Zoxc]

Is there a particular reason this is added to the path module and not on the Path type like other path methods?

[ChrisDenton]

Mainly just to be more or less a drop-in replacement for fs::canonicalize. And to avoid issues like: should Path::absolute take a base path? That said, I don't personally have any objection to it being a Path method.

[Zoxc]

The path module doesn't have any other path function currently, so I think adding it to Path as a drop-in for Path::canonicalize makes sense.

Resolving .. seems like a really useful usecase too, but it's probably better to make fs::canonicalize behave better on Windows for that.