On Mon, Apr 8, 2019 at 12:36 AM Tony Papadimitriou <to...@acm.org> wrote:
> (Apologies if this message appears twice – I’m having some SMTP issues.) > This mailing list isn't used any more. The forum is now the preferred channel: https://fossil-scm.org/forum > I attempted to minimize storage by running “fossil reb --compress” on > various fossils. Only one result was unexpected. > Below is a copy of the db --db-check before and after a REBUILD with > –-COMPRESS option. The ‘after’ is counting one file less. > > 1. What could be the reason for that (4299 files instead of 4300)? > Possibly a shunned artifact. 2. Is there some way to find out which file is missing by comparing to a > backup? > You can use use sqlite's "ATTACH" command to attach both the new and old DBs and do a SELECT to find the extra blob.uuid entry in the older copy. There's a CONTENT() SQL function (via fossil's built-in copy of the sqlite shell) to get the full, uncompressed content of a blob, but it outputs using sqlite's hex-encoded mode, and i'm not sure how to get it unencoded: echo "select content('rid:1')" | fossil sqlite3 -R repofile replacing 'rid:1' with the UUID of the newly-missing artifact. 3. Is it safe to assume (based on the db –db-check command) that the repo > is not corrupt in any way? > Definitely. -- ----- stephan beal https://wanderinghorse.net/home/stephan/ <http://wanderinghorse.net/home/stephan/> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
