sinelaw/fresh · error · io::Error (Unsupported)
Filesystem not available
Error message
Filesystem not available
What it means
NoopFileSystem is a stub implementation of the filesystem trait used in tests/headless contexts. Every filesystem operation on it funnels through the private unsupported() helper, which returns io::ErrorKind::Unsupported with the message 'Filesystem not available'. It signals that no real filesystem is backed by this model instance.
Solutions
- Construct the model/session with a real filesystem implementation instead of NoopFileSystem
- If this is a test, either assert on the Unsupported error or switch to a tempdir-backed filesystem
- Guard filesystem-touching code paths so they are skipped when the backend is NoopFileSystem
Example fix
// before
let model = Model::new(NoopFileSystem::default());
model.read_file("/tmp/x.txt")?; // Unsupported: Filesystem not available
// after
let model = Model::new(RealFileSystem::new());
model.read_file("/tmp/x.txt")?; Defensive patterns
Strategy: validation
Validate before calling
fn has_real_fs(model: &Model) -> bool { !std::ptr::eq(model.fs_type_id(), &std::any::TypeId::of::<NoopFileSystem>()) } // or track a bool at construction Type guard
fn is_noop_fs(fs: &dyn FileSystem) -> bool { fs.as_any().is::<NoopFileSystem>() } Try / catch
match model.write_file(path, data) { Err(e) if e.kind() == io::ErrorKind::Unsupported => eprintln!("no filesystem backend"), other => other?, } Prevention
- Never ship NoopFileSystem in production paths; reserve it for tests
- Centralize model construction so the fs backend choice is explicit
- Add a debug_assert that real file operations aren't routed to the noop backend
When it happens
Trigger: Any filesystem operation (read, write, metadata, listing) invoked on a model/session constructed with NoopFileSystem — typically headless tests, scripting sessions, or runs where the model was explicitly created without a real filesystem backend.
Common situations: Running editor logic in tests or CI with NoopFileSystem::default() as the backend; forgetting to swap in a real filesystem implementation before exercising file operations; using a script or harness that hardcodes the noop backend.
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
AI-assisted analysis of sinelaw/fresh@67894ca546 (2026-09-13).
Data as JSON: /api/errors/af4f12d1c6495907.
Report an issue: GitHub.
Appendix: source
Thrown at crates/fresh-editor-core/src/model/filesystem.rs:1641
}
Ok(())
}
}
// ============================================================================
// NoopFileSystem Implementation
// ============================================================================
/// No-op filesystem that returns errors for all operations
///
/// Used as a placeholder or in WASM builds where a VirtualFileSystem
/// should be used instead.
#[derive(Debug, Clone, Copy, Default)]
pub struct NoopFileSystem;
impl NoopFileSystem {
fn unsupported<T>() -> io::Result<T> {
Err(io::Error::new(
io::ErrorKind::Unsupported,
"Filesystem not available",
))
}
}
impl FileSystem for NoopFileSystem {
fn read_file(&self, _path: &Path) -> io::Result<Vec<u8>> {
Self::unsupported()
}
fn read_range(&self, _path: &Path, _offset: u64, _len: usize) -> io::Result<Vec<u8>> {
Self::unsupported()
}
fn write_file(&self, _path: &Path, _data: &[u8]) -> io::Result<()> {
Self::unsupported()
}View on GitHub (pinned to 67894ca546)