rust-lang/rust · error

file locks not supported on this platform

Error message

file locks not supported on this platform

What it means

Returned by Lock::new on platforms for which rustc_data_structures has no native file-locking backend. The cfg_select! in flock.rs only wires linux/redox/unix/windows to a real lock implementation; every other target falls through to the unsupported module, whose new() unconditionally returns Err(io::Error::new(ErrorKind::Other, msg)). The platform simply cannot honor the file-locking contract, so callers must treat any lock attempt as a hard failure.

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 22057b88b0)

Solutions

1. Run the tooling on a supported target (any unix, windows, or redox) where Lock has a real impl
2. If you only need the crate as a library dependency, avoid code paths that take a Lock
3. For wasm tooling, replace the file-locking requirement with a higher-level coordination mechanism
4. Confirm the target triple is what you expect (rustc -vV) before assuming support

Example fix

// before
use rustc_data_structures::flock::Lock;
let _l = Lock::new(&p, true, false, true)?;  // Err on wasm
// after: gate or skip locking on unsupported targets
#[cfg(any(unix, windows))]
let _l = Lock::new(&p, true, false, true)?;

// Detect platforms where rustc's flock is the `unsupported` impl, and avoid
// relying on exclusive file locking there.
cfg_if::cfg_if! {
    if #[cfg(any(windows, unix))] {
        const FLOCK_SUPPORTED: bool = true;
    } else {
        const FLOCK_SUPPORTED: bool = false;
    }
}

fn can_use_file_lock() -> bool { FLOCK_SUPPORTED }

// before calling any API that internally locks (e.g. incremental cache, dep graph):
// if !can_use_file_lock() { switch_to_lock_free_mode(); }

// Capability probe: try a real flock on a temp file; if it returns the
// "unsupported" path it will error immediately.
use std::fs::File;
use fs2::FileExt;

fn flock_supported() -> bool {
    let tmp = std::env::temp_dir().join(".flock_probe");
    match File::create(&tmp) {
        Ok(f) => match f.try_lock_exclusive() {
            Ok(()) => { let _ = f.unlock(); true }
            Err(_) => false,
        },
        Err(_) => false,
    }
}

use rustc_data_structures::flock;

fn acquire_or_fallback(path: &Path) -> LockHandle {
    if flock_supported() {
        match flock::Lock::new(path) {
            Ok(g) => LockHandle::Exclusive(g),
            Err(_) => LockHandle::Fallback,
        }
    } else {
        // platform has no flock; fall back to a process-level guard so the
        // rest of the pipeline still runs single-writer.
        LockHandle::Fallback
    }
}

enum LockHandle {
    Exclusive(rustc_data_structures::flock::Lock),
    Fallback,
}

When it happens

Trigger: Any code path that calls rustc_data_structures::flock::Lock::new on a target_os that is not linux, redox, another unix, or windows (e.g. wasm32-wasi, wasm32-unknown-unknown, certain bare-metal or hermetic targets). The function does not consult its arguments and always returns the Err.

Common situations: Building or running rustc/rustdoc-tier tooling on wasm or an unsupported tier-3 target; compiling a tool that depends on rustc_data_structures for a target without OS file locks; attempting to use incremental compilation locking on such a target.

AI-assisted analysis of rust-lang/rust@22057b88b0 (2026-08-03). Data as JSON: /data/errors/6be69f8283e5a471.json. Report an issue: GitHub.