aboutsummaryrefslogtreecommitdiff
path: root/lockchain-files/src/fs (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Running rustfmtKatharina Fey2019-04-221-2/+4
|
* Updating crates to 2018 edition (#9)Katharina2019-04-221-6/+6
| | | | | | * Updating main README * Updating lock file * Updating crate ecosystem to Rust 2018 edition
* Assorted changesKatharina Fey2018-09-162-6/+18
|
* Only relying on the `UserStore` `AutoEncoder` impl for serialisationKatharina Fey2018-09-162-2/+4
|
* Adding primitive file utilitiesKatharina Fey2018-09-162-33/+70
|
* A large batch of refactoring in FileVaultKatharina Fey2018-09-152-0/+157
Okay what am I doing here? If you're reading this in the future, it probably means I made some bad decisions. First: I'm sorry. Secondly: let me explain why I did what I did... Until this point `FileVault` has been a very transparent structure. It didn't really interact with the data much, basically solving all fs operations with streamed iterators and making sure stuff was done correctly, but not adding any depth on top of that. This needed to change... This isn't quite done and most of the code just breaks here ;) But the idea is to have `FileVault` be an intelligent wrapper around the filesystem. That means that not only does it cache certain operations for speed, it also keeps a selective index of files that exist. So for example, `Headers` were added here, that are always kept in sync with the FS. But only certain Records are stored (not only for security but also size consearns). After this refactoring is done (I shall write another long commit) the FileVault will act more as it's own type than just a simple, linear `Vault<T>` implementation.