Libraries

• fuser
• rust-vfs
• dokan-rust

Features (that I want)

• Archiving tools into a single binary.

• Low (if possibly, Zero) overheads

• Cross-platform supports.

  • Linux
  • MacOS
  • Windows

• No dynamic libraries are required (except proprietary OS pre-installed system libraries).

• Read-only binary (no FS writing).

• A feature like a daemon mode.

  • To save process duplications.

  • Can it be realized through a UNIX or TCP socket (like it that responds to the metadata of current running nodylibs processes)? 🤔

• Togglable caching features if possible. But the default strategy must be no caching.

• A feature that resolves the dependent dynamic linking libraries at the archiving time.

• Keep fast at the runtime, even if archiving is slow.

• To extract and modify paths command.

• Configuration system for the data dependencies (such as useful for dotfiles management).

  • It may require running some init scripts. It's useful to manage dotfiles.

Implementations

Binary format

• Using .tar archive format:

  • There's no reason why not to use it! 😼

The directory structures in .tar

example

root.tar
├── bin (executables)
│  ├── bar.elf (Linux)
│  ├── bar.exe (Windows)
│  └── bar.macho (MacOS)
├── data (data)
│  ├── bar.txt (text document)
│  ├── bar.jpg (JPEG image)
│  └── bar.png (PNG image)
├── init.toml (known information)
└── lib (dynamic libraries)
   ├── libfoo.dll (Windows)
   ├── libfoo.dylib (MacOS)
   └── libfoo.so (Linux)

• init.toml contains the information that knew at the archiving time. It doesn't have to be in .toml format. It should be in a binary format better.

  • The mapping of the structure?
  • file info that can know at the archiving time.

• bin directory has some executable format binaries.

• lib directory has some dynamic linking format binaries.

  • They must be resolved and collected at the archiving time.

  • Some optional files are allowed as inputs at the archiving time!

• data directory has any type of binary.

implements as a loader?

pros

• It will run in any environment.

cons

• It is the most difficult implementation because it requires a deep understanding of low-level programming.

• I don't assume that I can implement it 😇

implementation

• Study hard about low-level programming!

conclusion

• The loader method is not realistic.

implements as a filesystem?

pros

• In a POSIX-like environment, it will probably get high performance with low overheads.

cons

• Maybe, FUSE methods cannot use in MacOS without the mac-fuse library...

• It will spend coding costs hard to support cross-platform.

• In a Windows environment, it won't get enough performance...

implementation

• Using Dokan for Windows support? (There's a wrapper for Rust.). Or using WinFsp

  • WinFsp is licensed under GPL-v3. is licensed under GPL-v3...

  • Dokan(y) is licensed under LGPL.

• Using FUSE for POSIX-like OS supports?

• Mounting on TMPDIR in *nix environments.

implements as ...

Workflow