The File Filesystem (2021)

Original Article ↗ Hacker News Discussion ↗

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.