Julian Foad wrote on Tue, 02 Jun 2020 13:05 +0100: > Daniel Shahaf wrote: > > Julian Foad (Jira) wrote on Mon, 01 Jun 2020 11:20 +0000: > >> Two clues strongly suggest the corruption was originally caused by a bug > >> rather than hardware corruption: ⋮ > >> * although an off-by-4 can sometimes be a 1-bit error, this particular > >> one (41271 vs. 41275) is not a 1-bit error. > >> * the checksum on the node-revision must account for the corrupted data, > >> otherwise a checksum error is thrown instead;
> > Is there any chance that this _was_ originally a 1-bit error and then > > some offset got added/subtracted to both the id in the noderev header > > and the id in the directory rep? > > Technically I expect that's possible but it seems less likely. Does the rev file assembly code add/subtract offsets in such a manner? > It would have to have happened at original commit time in the > transaction construction and commit time, whereas I suspect (without > research) that a bit error is much more likely to occur in data at > rest on disk for years. But as you said yourself, a bit error in data at rest wouldn't have caused the dir rep's checksum to end up being correct. Can't we rule that scenario out, then? I'm not sure what else might have caused this. The only off-by-4 I can think of is the magic bytes of svndiff streams (e.g., subversion/libsvn_fs_fs/cached_data.c:1597; «rs->current == 4» at that point), but this could well be unrelated. Cheers, Daniel
