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


>  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?


----- stephan beal
"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

Reply via email to