FAfabricio.arce
ES
← Journal
Devlog

Ferrox: a snapshot of the VFS and alpha CLI

A technical note based on the public repository. What exists in the core, what the added tests check, and what remains on the roadmap.

Ferrox ↗
RustVFSCLITesting

Scope of this note

This entry opens the Ferrox journal with a documentary review of existing code, not a new release announcement or a reconstruction of development sessions. The reference is commit f8661c3, dated September 6, 2026.

Separating the core from the interface

ferrox-core exposes a FileSystem trait and a LocalFileSystem implementation. The CLI calls that contract to list, inspect metadata, create, remove, rename and search entries.

This separation keeps presentation outside the backend. Directory-first ordering and size formatting belong to the CLI; disk access belongs to the core. The TUI is still a placeholder, so reuse from a second interface is a design direction, not a completed integration.

Tests added to the backend

The reference commit adds unit tests for local-backend operations. The reviewed file contains eight cases: listing a file, creating a directory, file metadata, positive and negative existence checks, removal, renaming and search within a subdirectory.

The cases use temporary directories, separating those scenarios from the user’s files. This does not establish coverage of every edge case. The Ferrox test suite was not executed while preparing this note; the verifiable claim is that these cases are present in the code.

To check the state of a local project checkout:

cargo test --workspace
cargo fmt --check
cargo clippy --workspace -- -D warnings

These commands are verification instructions, not a record of obtained results.

Observed limitations

  • Search uses case-sensitive substring matching, not fuzzy matching.
  • find traverses with an explicit stack and skips directory-read errors.
  • The VFS interface remains synchronous.
  • The TUI does not implement navigation or panels.

The roadmap includes asynchronous I/O, fuzzy search and a three-pane TUI. None of those plans should be presented as a result of this version.

Useful next evidence

A subsequent entry could record an actual test run, including the code revision, environment and output; or explain a specific change alongside its commit. This keeps the journal clear about the difference between planned, implemented and verified work.

Sources

← Project journal