tinyhumansai/openhuman · error

acquire workspace write flock: {e}

Error message

acquire workspace write flock: {e}

What it means

Taking the exclusive flock on .memory-write.lock failed with the OS error {e}. The file opened, but lock_exclusive refused — typically because another process holds the lock and flock errored (e.g. on NFS or a filesystem without flock support), not merely because it was busy (flock blocks rather than errors in that case).

Source

Thrown at src/openhuman/tools/impl/filesystem/update_memory_md.rs:89

                return Err(anyhow::anyhow!(
                    "workspace lock file {lock_path:?} is a symlink; refusing to follow it"
                ));
            }
        }
        let mut opts = std::fs::OpenOptions::new();
        opts.create(true).write(true).truncate(false);
        #[cfg(unix)]
        {
            // O_NOFOLLOW closes the TOCTOU window: if a symlink is swapped in
            // after the check above, the open fails (ELOOP) rather than follows.
            use std::os::unix::fs::OpenOptionsExt;
            opts.custom_flags(libc::O_NOFOLLOW);
        }
        let file = opts
            .open(&lock_path)
            .map_err(|e| anyhow::anyhow!("open workspace lock file {lock_path:?}: {e}"))?;
        file.lock_exclusive()
            .map_err(|e| anyhow::anyhow!("acquire workspace write flock: {e}"))?;
        Ok::<std::fs::File, anyhow::Error>(file)
    })
    .await
    .map_err(|e| anyhow::anyhow!("workspace lock task join failed: {e}"))?
}

/// Atomically replace `path`'s contents with `content`.
///
/// Writes to a sibling temp file in the same directory (so the rename stays on
/// one filesystem and is atomic) and `rename`s it over the target. A crash
/// mid-write leaves either the old file or the complete new file — never a
/// half-written truncation. Callers MUST hold the per-workspace write lock so
/// the read-modify-write is serialized end-to-end.
async fn atomic_write(path: &Path, file: &str, content: &str) -> anyhow::Result<()> {
    let dir = path
        .parent()
        .ok_or_else(|| anyhow::anyhow!("target path has no parent directory"))?;
    let seq = TEMP_FILE_SEQ.fetch_add(1, Ordering::Relaxed);

View on GitHub (pinned to 7491200858)

Solutions

1. Read {e}: unsupported-filesystem errors mean the workspace must live on a local filesystem
2. Ensure no stuck process holds the lock (check lsof/fuser)
3. Retry after clearing the conflicting holder

When it happens

Trigger: Thrown at src/openhuman/tools/impl/filesystem/update_memory_md.rs:89 when the library encounters an invalid state.

Common situations: See trigger scenarios.

AI-assisted analysis of tinyhumansai/openhuman@7491200858 (2026-08-17). Data as JSON: /api/errors/15cd68ae61403d8c. Report an issue: GitHub.