On Wed, Apr 01, 2020 at 10:50:12PM +0300, Denis Kovalchuk wrote:
> > > 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
>
Great. Thank you, too, for following up and explaining the problem!
I will again wait a while to see if voting in STATUS happens over the
next few days. My opinion is that, ideally, we should get all current
entries in STATUS reviewed and merged, and then roll the -rc2 release.
Received on 2020-04-01 21:54:17 CEST