On Wed, Apr 01, 2020 at 06:25:12PM +0200, Stefan Sperling wrote:
> On Wed, Apr 01, 2020 at 11:45:04AM -0400, Nathan Hartman wrote:
> > On Wed, Apr 1, 2020 at 8:05 AM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > > The failure is 100% reproducible with «./svnadmin_tests.py
> > > --fs-type=fsfs --fsfs-version=6 74» on Linux.
> >
> > I'm experimenting with this also. So far I have nothing definitive but
> > I can confirm that it is 100% reproducible on Linux with the above
> > invocation.
>
> Also on OpenBSD. Thanks Daniel for identifying a way to reproduce it :)
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?
Index: subversion/libsvn_fs_fs/fs_fs.c
===================================================================
--- subversion/libsvn_fs_fs/fs_fs.c (revision 1875921)
+++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
@@ -2393,6 +2393,10 @@ reindex_node(svn_fs_t *fs,
SVN_ERR(svn_fs_fs__read_noderev(&noderev, rev_file->stream,
pool, pool));
+ /* Make sure EXPANDED_SIZE has the correct value for every rep. */
+ SVN_ERR(svn_fs_fs__fixup_expanded_size(fs, noderev->data_rep, pool));
+ SVN_ERR(svn_fs_fs__fixup_expanded_size(fs, noderev->prop_rep, pool));
+
/* First reindex sub-directory to match write_final_rev() behavior. */
if (noderev->kind == svn_node_dir)
{
Received on 2020-04-01 18:40:38 CEST