Remove `arc::handle_prefix()` about path_abs HOT 6 CLOSED

from path_abs.

I'm working on this right now, actually! I just figured I should have an issue number to mention in the commit that makes the change.

Sure, I'd love to help. :)

from path_abs.

Cool, you've been added as a collaborator.

I actually mistakenly thought this was the PR in the email. Carry on 😄

from path_abs.

A couple of days ago I discovered the problem that arc::handle_prefix() was intended to solve had not gone away, and I figured out how to reproduce it reliably. The following table is one I posted to rust-lang/rust#49342 but with a few more interesting test-cases I thought of in the mean time. As before, the intersection of each column and row represents the result of std::env::set_current_dir(column); Path::new(row).canonicalize() where "-" means "returned an error":

When the current directory is a regular (C:\) or UNC (\\vboxsvr\Shared) path, you can canonicalize just about anything, so we don't have to do anything special to make canonicalization work for those cases.

The path C:Users fails to canonicalize for both the extended-length (\\?\C:\) and UNC paths, which makes sense. As the C: row reveals, in those cases the current directory on C: is "\Users\IEUser" which does not contain a Users directory, so .canonicalize() is correct to return an error in those situations. We don't have to do anything special to make canonicalization work for those cases (beyond the work we already have to do to support canonicalizing non-existent paths).

The paths \Users and \ fail to canonicalize when the current directory uses extended-length syntax. Luckily, we can easily implement this ourselves:

• take the prefix from the current working directory (say, C:)
• add a root component (C:\)
• canonicalize that (\\?\C:\)
• add the remainder of the input path to that head (\\?\C:\Users)

So, in every situation we can produce a canonical path head for an arbitrary input path, even on Windows, and even if the current working directory uses extended-length path syntax.

I'm gonna try to re-implement PathArc::absolute() like that, and we'll see how far I get.

from path_abs.

from path_abs.

Not strictly related to solving this issue, but this Raymond Chen blog post explains a whole bunch of the weirdness I've encountered with relative path resolution on windows. The short version is: unlike Unix, where the shell is a thin wrapper over the kernel's idea of a "process", Windows' cmd.exe lies all the time.

from path_abs.