A simple archiving format made for game resources

So I was pretty impressed with how Godot stored its assets in a .pck file and serves them in a sort of virtual file system at runtime, rather than just shipping a resources folder. It is cleaner, prevents easy tampering and hides the game's resources. I searched for a similar crate in Rust, I found mlar and nothing else. If you know of any other crate, please ping me about it.

So a friend and I got to work designing the spec of vach, a custom archiving format. We discussed a lot, read several articles and wrote some code. We wanted it to be easy to use, memory efficient, tamper-conscious and low-overhead.

Extra emphasis on:

  • Cutting dependency costs.
  • The loader never loading all the data into memory at once.
  • General advice.
  • This part

So here I am kindly asking for y'all to review the code and give me your harshest criticisms. Here is the latest development repo and latest (incomplete) documentation. For sample usage, please refer to the tests' code, I haven't written any examples yet. I will gladly answer any questions asked. Thx in advance.

1 Like

Hey Newton!

If you know of any other crate, please ping me about it.

Searching crates.io for filesystem game I found the following:
assets_manager, distill, gvfs, hpk (there's more under the #assets keyword)


Repository README

  • the swear words in your README might be a bit off-putting for some users
  • Judging from your README it's unclear if encryption will be mandatory or optional.


  • Consider renaming your repo to vach, naming it sth different (virtfs-rs or vile) is a bit confusing. On a related note naming your CLI crate vach-cli is probably clearer than just vf.
  • you'll want a README for your crate (vach/README.md so that it shows up on crates.io)
  • you'll want module documentation for the crate so that it shows up on docs.rs (should include an example how to get started ... also comes with the advantage that the examples are tested by cargo test).
  • Your documentation speaks of archive source several times but never explains what that is.
  • You have some typos e.g. Alows, exmalpes, can be accesses -> can be accessed, ...


  • homepage in your Cargo.toml should be repository
  • I'd also refine your tags #filesystem, #assets, #game, #compression seem more descriptive than #storage, #vach, #format, #secure.

Module structure

I don't see the appeal of putting all crate logic in a prelude submodule. I'd probably instead group the structs by purpose e.g. I'd put Keypair, PublicKey and SecretKey in one submodule for the crypto stuff. If the other structs are essential to your library I'd put them in the top level. If you want a prelude for importing you could still have one and just re-export everything.

1 Like
  • Thanks for the examples, I will check them out and compare them to my current crate.
  • Encryption is optional, but it's not yet implemented. Only compression and signing.
  • I will remove the cusswords from the description.
  • I will rename the repository vach as that's the main crate.
  • vf is a pending project, it is completely different from the CLI.
  • I will explain better what an archive source is, it's just basically anything that implements io::Read and io::Seek. It should also be a valid source of data according to the spec. Like a file or a slice.
  • I fixed most of the typos. I will check the rest in a spell-checker.
  • I will re-arrange the sub-modules too. I would really like some suggestions for how to do this
  • thx for the in-depth review

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.