The File Filesystem (2021)

Original Article ↗ Hacker News Discussion ↗

Mounting structured data formats as virtual filesystems—so that JSON objects or zip archives appear as regular directories and files—promises powerful new ways to use existing Unix tools for inspecting, transforming, and composing data. Commenters highlight practical use cases (on‑demand access to archives, CI caches, configuration modeling) and connect the idea to prior systems like MPW, Plan 9, Reiser4, and various FUSE-based tools. Skeptics point to limitations in mapping complex formats (especially XML, namespaces, lists, and odd keys) to a clean directory tree and to platform constraints, particularly on macOS, but many see this “everything as files” approach as a compelling extension of the Unix philosophy.

Overall reaction

  • Many commenters find the “file-as-filesystem” idea clever and fun, fitting the Unix “everything is a file” ethos.
  • Some note they’d still default to higher-level tools (e.g., JSON/DB/query tools) for most real work, so see this more as a neat hack than a daily driver.

Naming and prior art

  • The “ffs” name is criticized as overloaded: existing Fast/Formatted/Flash/Amiga file systems already use it, plus the colloquial expletive. Alternatives like “filefs” are suggested.
  • Others argue naming conflicts are minor since this targets different platforms.
  • Several historical precedents are mentioned: editors and IDEs exposing open buffers or selections as files, browsers/tabs-as-dirs, Plan 9 mechanisms, Reiser4’s file/dir hybrids, archive-mounting tools, and “everything via /proc”-style ideas.

Use cases and benefits

  • Popular use case: interactively browsing and searching JSON with regular filesystem tools (ls, grep, etc.).
  • General pattern: treating structured formats and “files inside files” as mountable FS to avoid explicit extraction and to reuse existing tools.
  • Concrete benefits cited:
    • On-demand access inside archives (e.g., CI caches in ZIPs) to avoid full extraction and speed builds.
    • Easier interoperability: producers/consumers speak a common FS abstraction instead of many bespoke converters.
    • Cleaner exploration of Git commits or other object hierarchies as directories.

Limitations and open questions

  • Missing formats: XML, CSV, Excel, PDF. XML in particular is seen as hard to map cleanly due to attributes, comments, processing instructions, DTDs, entities, and namespaces.
  • JSON modeling concerns:
    • Keys containing slashes.
    • Representing arrays, preserving order, and inserting elements without fragile renames.
    • Distinguishing arrays vs objects and representing hashes cleanly.
    • Risk of lossy or convoluted mappings.
  • One comment notes arrays are supported via extended attributes, but details remain thin.

FUSE, OS support, and macOS debate

  • Some dislike relying on FUSE (complexity, performance, kernel extensions), preferring native or specialized tools.
  • Others note many FUSE-based systems already mount archives and images; this fits an existing ecosystem.
  • Long subthread on macOS:
    • macOS lacks a public, general user-space FS API like FUSE; third-party solutions are kext- or NFS-based and fragile.
    • There appears to be an internal user-mode FS API gated by private entitlements.
    • Disagreement over Apple’s motives: some see hostility to developers, others argue it’s about security, stability, and maturing the API before opening it.