Re: [fossil-users] Release 1.35 checksums?

On 7/6/16, Eduard wrote: > > As a related small request, it would be very much appreciated if more > people (including D. R. Hipp) signed their commits with PGP (in addition > to the build hashes on the site). After all we already have the fossil > 'clearsign'

Re: [fossil-users] Release 1.35 checksums?

Faf? -Original Message- From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Eduard Sent: 6. juli 2016 19:40 To: Fossil SCM user's discussion Subject: Re: [fossil-users] Release 1.35 checksums? On 07/05/2016 02:56 PM, jungle

Re: [fossil-users] Release 1.35 checksums?

On 07/05/2016 02:56 PM, jungle Boogie wrote: > On 1 July 2016 at 09:39, Warren Young wrote: >> If you’re expecting the checksum to protect you against someone hacking the >> web site and uploading malware, they can modify the checksums on the web >> site at the same time. >

Re: [fossil-users] Bitrot defense?

Nice article. Short answer is yes, ZFS will heal a file regardless of size or level of activity on it, then. Not only that, but it would be a recommended configuration if you want to *rule out* bitrot/corruption for the the likes of "Need help /tips SQLITE_CONSTRAINT: abort at 42" (this mail

Re: [fossil-users] Bitrot defense?

[Default] On Wed, 6 Jul 2016 05:02:40 -0400, Paul Hammant wrote: > ZFS, Btrfs could repair a Fossil database inflight, and without hiccup? > Tell me a little more - it would repair sectors, blocks, segments of the > whole Fossil image? Or the whole image? It seems that

Re: [fossil-users] Bitrot defense?

> Those filesystems don’t need to know Fossil’s internals at all. >Self-repair only requires checksums and redundancy. If one checksum doesn’t match the contents of the data being checksummed, another copy of the data is checked, and if its contents match the checksum, it is presumed to be the