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

file locks not supported on this platform

Error message

file locks not supported on this platform

What it means

Returned by rustc_data_structures::flock::Lock::new on platforms that have no file-locking backend. The cfg_select! block in flock.rs selects a platform-specific module: linux for Linux/Redox, unix for other Unix, windows for Windows, and unsupported for everything else (the _ catch-all). The unsupported module's Lock::new unconditionally returns Err with this message. This means incremental compilation's file locking is entirely unavailable on such targets.

Solutions

1. If building rustc for a new platform, implement a flock backend in a new module under src/flock/ and add a cfg_select arm for your target_os.
2. As a workaround, disable incremental compilation (-C incremental=false or unset CARGO_INCREMENTAL) since the primary consumer of flock is the incremental compilation cache.
3. If on a mainstream platform, verify your target triple is correct — a misconfigured target can accidentally fall through to unsupported.
4. For WASM/wasi targets, use a different build strategy that doesn't rely on local file locking.

Example fix

// before: unsupported.rs always errors
pub fn new(_p: &Path, _wait: bool, _create: bool, _exclusive: bool) -> io::Result<Lock> {
    Err(io::Error::new(io::ErrorKind::Other, "file locks not supported on this platform"))
}
// after: disable incremental compilation to avoid flock
// in build config or environment:
//   CARGO_INCREMENTAL=0
//   RUSTFLAGS="-C incremental=false"

// Before relying on file locks, check if the platform supports them.
// On unsupported platforms, disable incremental compilation.
fn check_flock_available() -> Result<(), String> {
    let tmp = std::env::temp_dir().join("flock_test");
    std::fs::write(&tmp, b"").ok();
    match rustc_data_structures::flock::Lock::new(&tmp, false, false, true) {
        Ok(_) => { std::fs::remove_file(&tmp).ok(); Ok(()) }
        Err(e) => {
            std::fs::remove_file(&tmp).ok();
            Err(format!("file locks unavailable: {e}"))
        }
    }
}

// Lock::new returns io::Result<Lock>. In code that uses flock directly:
match rustc_data_structures::flock::Lock::new(path, wait, create, exclusive) {
    Ok(lock) => { /* use lock */ },
    Err(e) if rustc_data_structures::flock::Lock::error_unsupported(&e) => {
        // gracefully degrade — skip locking on unsupported platforms
    }
    Err(e) => return Err(e.into()),
}

When it happens

Trigger: Running rustc (or a tool that uses rustc_data_structures::flock, such as rustdoc or cargo) on a platform that is not Linux, Redox, macOS/other-Unix, or Windows. Examples include WASM targets, certain embedded OSes, or any target where none of the cfg_select arms match except _.

Common situations: Cross-compiling from an exotic host; running rustc under a WASM-based sandbox or container; building rustc itself for a tier-3 platform. On mainstream platforms (x86_64-linux, aarch64-darwin, x86_64-windows) this error should never appear.

Related errors

• process groups are not supported on espidf
• Accessing live loans requires `-Zpolonius=next`
• archive member at offset
• `async gen` closures not supported yet
• AsyncFn* are not yet const

AI-assisted analysis of rust-lang/rust@7088e4b63a (2026-08-10). Data as JSON: /api/errors/6be69f8283e5a471. Report an issue: GitHub.

Appendix: source

Thrown at compiler/rustc_data_structures/src/flock/unsupported.rs:10

use std::io;
use std::path::Path;

#[derive(Debug)]
pub struct Lock(());

impl Lock {
    pub fn new(_p: &Path, _wait: bool, _create: bool, _exclusive: bool) -> io::Result<Lock> {
        let msg = "file locks not supported on this platform";
        Err(io::Error::new(io::ErrorKind::Other, msg))
    }

    pub fn error_unsupported(_err: &io::Error) -> bool {
        true
    }
}

View on GitHub (pinned to 7088e4b63a)