Ok. I’m pretty sure that db/revs/7/7449 is just truncated. Since there aren’t any signs of any text readable data at the bottom of the file and the top of file looks similar to 7448, 7450 and to any other revision.
So, let’s say I’m 85.23% sure about content of this particular revision. How can I recreate revision from folder with files? This rev contains only add-dir and add-file changes. -- Dmitry Minsky > On 21.06.2022, at 09:54, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > Dmitry Minsky wrote on Sun, 19 Jun 2022 11:53 +00:00: >> There is something in revisions before and after corrupted one: >> >> % strings repo/db/revs/7/7448 | tail -1 >> 2244140591 fa0c1a8229575b0ce27ef0c5a8b898b4 2244140730 >> 7d861109493094a15013c7ea105e33a1W >> >> % strings repo/db/revs/7/7450 | tail -1 >> 51995736 59c66b6d95365e6bdb4be4ec3b2d3a34 51995799 >> 72059006b7c456b03efb7f07e0557795S >> >> But on corrupted (actual number of corrupted revision is 7449) it doesn't >> give anything meaningful >> >> % strings repo/db/revs/7/7449 | tail -1 >> Y$Q8 >> > > OK, so the last line isn't there at all. > > What you now need to do is figure out what happened to the revision > file. For starters, check whether the change-list portion (a list of > lines with "add-file" "modify-dir" and such on them, immediately > before «L2P-INDEX») is still there. > > - If that's the case, the file was likely truncated, but the lost > portion of the file can likely be reconstructed manually, though > perhaps with some effort (what's the size of db/revs/7/7449 in bytes > and the number of lines `svn log -qvr 7449`'s output should have?). > > - If it got truncated earlier, then it's likely that actual deltas > (PLAIN..ENDREP or DELTA..ENDREP) got truncated, i.e., data loss has > occurred, so you'd have to reconstruct the revision manually or > proceed without the lost data. > > - And if it's not merely truncated but otherwise corrupted, well, > it depends. > > Do you have any way to reconstruct the revision or its contents? Older > backups, mirrors, commit mails, a working copy that committed this > revision or updated to it and never got 'svn cleanup' run on it? > (The thinking being to exploit issue #4071; cf. > <https://subversion.apache.org/docs/release-notes/1.7#wc-pristines > <https://subversion.apache.org/docs/release-notes/1.7#wc-pristines>>.) > > Reminder that revision files contain binary data and should not be > opened by editors that auto-fix whitespace and so on. And that > repositories should be backed up before being manually operated on. > >> % < repo/db/revs/7/7449 xxd -s Y$Q8 -l 9 >> 00000000: 4445 4c54 410a 5356 4e DELTA.SVN >> > > That's likely because xxd(1) calls atoi(3) on its argv[2], which > (assuming the shell parameter «Q8» is unset) has the value «Y», so the > function call returns 0. > > The output appears sane, though. These bytes are exactly what the > start of a revision file might look like. > > Cheers, > > Daniel > > P.S. For any future FSFS hackers out there, note that it's likely r7449 > added a file or a directory. (Why? Because gung bhgchg fubjf > n /frys-pbzcerffrq/ qrygn.) > >> On Sun, Jun 19, 2022 at 12:19 PM Daniel Shahaf <d...@daniel.shahaf.name> >> wrote: >> >>> Dmitry Minsky wrote on Sat, 18 Jun 2022 17:16 +00:00: >>>> I have a pretty old repository and now going to move it to another >>> machine. >>>> When I start the dump process I stumbled upon this error in one of the >>> old >>>> revisions: >>>> >>>> svnadmin: E16004: Invalid r4422 footer >>>> >>> >>> It's actually E160004. (Just saying this so search engines will find this >>> thread.) >>> >>>> I now workaround with a skip over corrupted revision and continue >>>> --incremental dump. But like every 10-50 revisions I still get this error >>>> because I suppose there are files that depend on something from this old >>>> corrupted revision. The question is, how and where to look in this >>> revision >>>> so I could manually fix the error by changing some files or checksum or >>>> anything? >>> >>> At the very end of the file, like the following but on db/revs/4/4422: >>> >>> % strings db/revs/0/1 | tail -1 >>> 417 b4657c89ff644471b6760fd6389d253c 445 ea755737e485eeb03c0012e5d6bc1b49I >>> % < r/db/revs/0/1 xxd -s 417 -l 9 >>> 000001a1: 4c32 502d 494e 4445 58 L2P-INDEX >>> % < r/db/revs/0/1 xxd -s 445 -l 9 >>> 000001bd: 5032 4c2d 494e 4445 58 P2L-INDEX >>> % >>> >>> (The first command might pick up some of the P2L/L2P data too? I don't >>> remember whether it's guaranteed that there'll be a non-printable >>> character between that and the last line.)
