Per https://github.com/cberner/fuser/issues/153#issuecomment-864348771, better to rely on the explicit contract than on the the current implementation in fuser calling mem::drop.

Broad refactor of how things work.

Adds support for TOML, along with CLI stuff for setting formats (which are automatically inferred from filenames).

You can convert between things!

• [x] ~~choose target~~ ba64e76
• [x] ~~actually output~~ ba64e76
• [x] ~~fsync causes output (see #4)~~ doesn't seem to actually work; see 867cb6b for broken test

Trying to mount a JSON file within the virtual filesystem fails (which is ok, I guess):

raphael@tukk ~/Downloads> ./ffs -i ffs1.json raphael@tukk ~/Downloads> cat ffs1.json {"option":"test"} raphael@tukk ~/Downloads> cp ffs1.json ffs1/ raphael@tukk ~/Downloads> ls ffs1/ ffs1.json option raphael@tukk ~/Downloads> ./ffs -i ffs1/ffs1.json fusermount: bad mount point ffs1/ffs1: Permission denied thread 'main' panicked at 'called Result::unwrap() on an Err value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:38:41 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

This actually creates the subdirectory ffs1/ffs1 but does not mount anything there. Unmounting the filesystem results in an additional entry "ffs1: {}" in the json file. I'd suggest that a failed command should not leave behind any new files/members.

The JSON object { ".": 5 } will create a file named dot holding the number 5... but it will dump back to JSON without restoring the name.

The best solution is probably to track an "unmunged" name, and files that don't undergo a rename call go back exactly how they were.

This unmunged name is metadata, so the appropriate mechanism for working with it is up in the air (see #2).

Rather than taking a mountpoint as an argument, use an optional --mount flag.

If the input is over STDIN, you have to specify a --mount.

If the input is from a file foo.EXT, then try to make a directory foo. If that file already exists, give up and tell the user about --mount. If it doesn't, great: do that. When things unmount, double check the directory is empty and then remove it.

Need to revise all the tests, and then test a few configurations of this feature.

Investigate weird unmounts on macOS, producing:

WARN fuser::mnt::fuse2: umount failed with Os { code: 22, kind: InvalidInput, message: "Invalid argument" }

See actions log. Linux seems fine.

Lazily populate the FS. The current implementation passes tests but has hefty technical debt.

• [x] Rename fs.rs into eager.rs. 24d9704
• [x] Use the new Nodelike parsing/unparsing logic to simplify loading for eager::FS, too. 9268a77
• [x] Let lazy loading rewrite input into a different output format by calling resolve_node to fixpoint. aba72bc
• [x] CLI flags for controlling laziness. df22c78

It's tempting to have eager mode work with the lazy FS by just forcing resolution during startup. There would be some overhead, though. How much? We can do benchmarking on three modes: lazy, lazy with --force-early, and the existing eager. dd152f1 shows that lazy with --force-early is on par with eager. So once we can have lazy outputting in whatever format, we can drop eager entirely.

#42 reports an issue with nested mounts (which are just disallowed by FUSE and macFUSE), which we were handling poorly.

Check that mount2 worked correctly and report messages.

$> touch x.json $> ffs x.son thread 'main' panicked at 'JSON: Error("EOF while parsing a value", line: 1, column: 0)', src/format.rs:187:53 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

An idea from @angelhof: notice directories where every file has numerical name suffixes (e.g., role0, role1, or simpliciter 0, 1, 2, ...) and automatically treat them as lists.

The best way to do this is to use the auto type for directories, too, and new directories have that type assigned.

On a malformed JSON file:

: mgree@rocinante:~/talks/20211025plos [master] ; ~/ffs/target/release/ffs -i demo.json 
thread 'main' panicked at 'JSON: Error("expected value", line: 7, column: 12)', src/format.rs:322:45
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

For example i3blocks supports multiple signals which you can trigger using pkill -SIGRTMIN+10 i3blocks, which then causes an action.

Could you add atleast two signals, one for re-reading INPUT file and another for writing OUTPUT file. This would open ffs for uses in scripts and would allow updating INPUT and/or OUTPUT files without needing to restart ffs.

Just load/unload data directly on the filesystem.

Progress indicator. https://docs.rs/indicatif/0.16.2/indicatif/

Multithreading? (Is that ever a performance win?)

Pack

BFS?

Unpack

Flag to follow symlinks, possibly even out of the root.

-i flag for prompting on weirdness.