rust-lang/cargo · error · io::Error

the path was not found

Error message

the path was not found

What it means

Windows-only. In `try_canonicalize` (src/util/mod.rs:159), when `std::fs::canonicalize` fails AND the fallback `path.try_exists()?` returns `false`, cargo synthesizes an `io::Error` with kind `NotFound` and this message so that callers see a consistent NotFound error similar to `canonicalize`'s behaviour on other platforms.

Source

Thrown at src/util/mod.rs:159

}

#[cfg(not(windows))]
#[inline]
pub fn try_canonicalize<P: AsRef<Path>>(path: P) -> std::io::Result<PathBuf> {
    std::fs::canonicalize(&path)
}

#[cfg(windows)]
#[inline]
pub fn try_canonicalize<P: AsRef<Path>>(path: P) -> std::io::Result<PathBuf> {
    use std::io::Error;
    use std::io::ErrorKind;

    // On Windows `canonicalize` may fail, so we fall back to getting an absolute path.
    std::fs::canonicalize(&path).or_else(|_| {
        // Return an error if a file does not exist for better compatibility with `canonicalize`
        if !path.as_ref().try_exists()? {
            return Err(Error::new(ErrorKind::NotFound, "the path was not found"));
        }
        std::path::absolute(&path)
    })
}

/// Get the current [`umask`] value.
///
/// [`umask`]: https://man7.org/linux/man-pages/man2/umask.2.html
#[cfg(unix)]
pub fn get_umask() -> u32 {
    use std::sync::OnceLock;
    static UMASK: OnceLock<libc::mode_t> = OnceLock::new();
    // SAFETY: Syscalls are unsafe. Calling `umask` twice is even unsafer for
    // multithreading program, since it doesn't provide a way to retrieve the
    // value without modifications. We use a static `OnceLock` here to ensure
    // it only gets call once during the entire program lifetime.
    *UMASK.get_or_init(|| unsafe {
        let umask = libc::umask(0o022);

View on GitHub (pinned to 0e07a15537)

Solutions

1. Confirm the path exists and is accessible from the working directory (`Test-Path`, `dir`).
2. Fix the manifest/config path that referenced the missing file or directory.
3. Re-create the resource (re-run `cargo vendor`, restore the checkout, remount the share).

Example fix

# before — vendored dir missing on Windows
[dependencies]
foo = { path = "vendor/foo" }   # vendor/ deleted
# after — regenerate vendor dir
cargo vendor vendor
# or correct the path

use std::path::Path;
fn exists_or_bail(p: &Path) -> std::io::Result<()> {
    if p.try_exists().unwrap_or(false) { Ok(()) } else { Err(std::io::Error::new(std::io::ErrorKind::NotFound, "missing")) }
}
// call exists_or_bail(path) before try_canonicalize on Windows

match cargo::util::try_canonicalize(&p) {
    Err(e) if e.kind() == std::io::ErrorKind::NotFound => { /* create or fix path */ }
    res => res,
}

When it happens

Trigger: Calling `cargo::util::try_canonicalize(p)` on Windows where `canonicalize` fails (e.g. due to the file living on a UNC/share path or a drive canonicalization quirk) and the path does not actually exist on disk.

Common situations: Windows builds referencing a path that was never created or was deleted (stale lockfile, missing vendored dir); case-sensitivity mismatches; mapped network drives disconnected; junction/symlink targets missing.

Related errors

• no executable for `{}` found in PATH
• `{feature}` is unsupported when inferring the crate name, us
• the crate `{dependency}` could not be found at `{source}`
• single file packages cannot be used as dependencies
• `{}` was defined in {} but could not be resolved with {}

AI-assisted analysis of rust-lang/cargo@0e07a15537 (2026-08-06). Data as JSON: /data/errors/f1413f5886f863c3.json. Report an issue: GitHub.