About the issue in the subject, I have a couple of considerations to share with you: 1) TAR / ZIP / etc. usually doesn't allow to delete or modify files from the archive without recreating it. They allow append, but not modify or delete. 2) HalFS and other "embedded filesystems" allows modify and delete very freely, but the creation of new files has a great issue: usually those filesystems need a "fixed size" storage. Even when a filesystem can grow, it usually can't "shrink" very easily.
Today I had a "strange" idea: why not using sqlite (an embedded database) for data storage? I tried a bit today, even with very large (100s of MB) binary files, and the time overhead seems very low from the first tests I made (10-15% more than a simple cp). The data size overhead is even smaller. Using that would give us on the pristine cache: 1) Portable transactional semantics. 2) Ability to store metadata (e.g. permissions). 3) Growable/shrinkable, single file storage. 4) A very solid backend (sqlite is used by Apple in Mac OS X for a lot of storage necessities, even if not for "raw filesystem storage"). The major hassle of this solution is that requires sqlite + HDBC (or something like that) as dependencies, but I think that this is something we can work on (sqlite can be "embedded" as a large .c file in any application). I need to do LOTS more performance tests (maybe with HDBC) before proposing (and maybe start implementing) this solution, but I want to hear your thoughts about this. Salvatore _______________________________________________ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
