rust-lang / rust-lang/cargo

Windows device path and long-path meta issue.

Open
#9,770 18 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

A-filesystem E-hard O-windows S-needs-design
Dominant language
Rust
Stars
15.5k
Forks
3k
Avg merge
23h 30m
Merged PRs (30d)
51

Description

This is a meta issue to coordinate the different issues related to handling device paths and long paths on Windows (such as \\?\ or \\.\). There are several places where Cargo does not handle these well, but it is not clear exactly how they all should be approached. Changes for these require careful consideration, and it's not clear what a general good approach would look like. Some rough thoughts to consider:

  • Where exactly are the problems? (Making a very clear overview would be an extremely helpful way to help here!)
  • To what degree should we strive for long-path support? Having the target directory exceed MAX_PATH seems like it would be quite difficult due to issues like https://github.com/rust-lang/rust/pull/86406. Manifests require a registry setting that is off by default.
    • If we don't or can't support MAX_PATH paths, does it make sense to ever use device paths? Can they just be converted to normal paths and make Windows handle its regular normalization?
    • Is supporting long paths feasible without a manifest?
  • Should the fixes be primarily done to the standard library?
  • Should Cargo use an external library (like dunce), or should it all be internal? What should be done with normalize_path?
  • How to approach normalization/canonicalization? There are classic issues like whether to follow symlinks, but also the troubles of using's Rust's canonicalize function on Windows.
  • Should Cargo try to avoid device (aka verbatim) paths as much as possible?
  • Are there other ways to lean on Win32 normalization (like \\.\ or GetFullPathNameW)?
  • Should it try to use \\?\GLOBALROOT\ style paths (see https://github.com/rust-lang/rust/pull/86447)?
  • Is it feasible to just translate \\?\ paths to \\.\, and rely on the Win32 API to do normalization? This would not support long-paths, but there are many other problems with long paths. (Probably not, just tossing out the idea.)

Linking issues and PRs:

  • PR #8964 — Another fix for workspace path joining
  • PR #8881 — Fix --manifest-path for verbatim paths
  • PR #8874 — Append workspace paths using components
  • Issue #8626 — Crash when using \?\ style path on Windows
  • Issue #7986 — Add longPathAware to the app manifest on Windows
  • PR #7729 — fixed workspaces issues due to non-canonical manifest path
  • Issue #7686 — Workspace path is not fully resolved
  • Issue #7643 — Crash on non-absolute path in Windows
  • Issue #13020 — Failure to load git dependencies with long file names on Windows
  • Issue #6198 — "Package collision in lockfile" using UNC/root local device/etc paths
  • Issue #2516 — Crate failed to unpack on Windows (os error 3) - path name too long
  • Issue #13141 — Investigate better Windows long-path error handling
  • Issue #13919 — Windows \\?\ verbatim paths break idiomatic use of OUT_DIR and include!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with normalize_path in crates/cargo-util/src/paths.rs and review the linked Windows path issues and pull requests to build the missing problem overview. Define a feasible scope for device-path and long-path handling, including whether changes belong in Cargo or the standard library; done means an agreed approach and clearly scoped follow-up work.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
build-system, operating-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.