> > This seems to fix it.
> >
> > I don't understand why this is necessary but the regular code path for
> > access to node revision data in fsfs also seems to apply this always.
> >
> > Can an fsfs expert confirm?
>
> Since this fix looks reasonable to me and we're trying to move the release
> process forward, I have decided to commit the change and have added it to
> the backport nomination as well.
I had the same diff in my working copy and can confirm it fixes the problem.
Because the root cause of the problem was unclear to me I investigated it.
svn_fs_fs__fixup_expanded_size() function exists due to issue SVN-4554 [1].
In this case, fsfs-v6 repository created with older binaries contains a
representation with "expanded size" field written on disk as 0. The fsfs code
assumes that this field has resolved value after the fixup, but because of the
missing calls it did not and contained 0. It caused the read representation
contents to be truncated to size of 0. In this case it is a directory
representation
and so the call to svn_fs_fs__rep_contents_dir() resulted in error. The error is
a checksum mismatch error where the actual checksum is a checksum of the
(truncated) empty string and the expected checksum is the one recorded in
the revision file.
Thanks for your help and the fix!
[1] https://issues.apache.org/jira/browse/SVN-4554
Received on 2020-04-01 21:50:37 CEST