astrid-runtime/astrid · error · io::Error

durable layout records are unsupported on this operating sys

Error message

durable layout records are unsupported on this operating system

What it means

atomic_write only implements durable atomic layout-record writes for unix and windows. On any other target family it returns ErrorKind::Unsupported with this message, because there is no portable way to create, rename, and fsync files there. It is a compile-time-target limitation, not a runtime data problem.

Source

Thrown at crates/astrid-core/src/dirs_layout.rs:556

            },
            Err(error) if error.kind() == io::ErrorKind::NotFound => {},
            Err(error) => return Err(error),
        }
        let mut file = OpenOptions::new()
            .write(true)
            .create_new(true)
            .mode(0o600)
            .open(&staged)?;
        file.write_all(bytes)?;
        file.sync_all()?;
        crate::platform_fs::rename_with_write_through(&staged, path)?;
        File::open(parent)?.sync_all()
    }

    #[cfg(not(any(unix, windows)))]
    {
        let _ = (path, bytes);
        Err(io::Error::new(
            io::ErrorKind::Unsupported,
            "durable layout records are unsupported on this operating system",
        ))
    }
}

/// Validate and retire a legacy directory tree without following redirects.
///
/// The complete tree is checked for symlinks, special entries, filesystem
/// boundaries, and active mounts before bottom-up deletion. Directory fsyncs
/// make successful removal durable on hosted Unix filesystems.
///
/// # Errors
///
/// Returns an I/O error and leaves the tree untouched when validation finds a
/// redirect, special entry, filesystem boundary, or active mount.
pub fn retire_legacy_source_tree(path: &Path) -> io::Result<()> {
    retire_legacy_source_tree_impl(path)

View on GitHub (pinned to affd8760f4)

Solutions

1. Run the layout-writing code on a supported unix or windows target.
2. cfg-gate the call in your code for supported target families and provide a native-host migration step for other targets.
3. If you need another platform, contribute a platform-specific atomic_write implementation (create temp + rename + fsync) rather than bypassing the guard.

Example fix

// before (unsupported target)
write_layout_version(&dir.join("layout.json"), &record)?;
// after
#[cfg(any(unix, windows))]
write_layout_version(&dir.join("layout.json"), &record)?;

fn durable_layout_supported() -> bool {
    cfg!(any(unix, windows))
}

fn platform_supports_atomic_layout_writes() -> bool {
    cfg!(unix) || cfg!(windows)
}

match write_layout_version(path, record) {
    Err(e) if e.kind() == io::ErrorKind::Unsupported => {
        // run layout writes on a supported host instead
    },
    other => other?,
}

When it happens

Trigger: Calling write_layout_version (or anything that admits/writes canonical layout records) when compiled for a target that is neither unix nor windows (e.g. wasm, os-less embedded).

Common situations: Cross-compiling the crate for wasm or an embedded target and invoking layout migration/record-writing code; CI running a non-unix/non-windows target triple.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors

• failed to persist {}: {e}
• layout migration capacity probing is unavailable in a WebAss
• layout record has no parent
• layout record has no file name
• layout staging path is redirected: {}

AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09). Data as JSON: /api/errors/740d28e2d18bc536. Report an issue: GitHub.