You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@subversion.apache.org by "Stefan Fuhrmann (JIRA)" <ji...@apache.org> on 2016/10/25 19:11:58 UTC

[jira] [Created] (SVN-4658) Can't reconstruct fulltext from DELTA against PLAIN in FSFS

Stefan Fuhrmann created SVN-4658:
------------------------------------

             Summary: Can't reconstruct fulltext from DELTA against PLAIN in FSFS 
                 Key: SVN-4658
                 URL: https://issues.apache.org/jira/browse/SVN-4658
             Project: Subversion
          Issue Type: Bug
          Components: libsvn_fs_fs
    Affects Versions: 1.9.4
         Environment: All
            Reporter: Stefan Fuhrmann
            Assignee: Stefan Fuhrmann


A DELTA representation against a PLAIN delta base will not be
reconstructed correctly if

  * it spans multiple txdelta windows (100kB), and
  * there is a match against the base in one window W, and
  * there has been no match against the base in the previous window W-1,

because the matching data is being taken from W-1 or earlier instead
of W.  This causes an MD5 checksum mismatch and the data cannot be
read.

In repositories only written to by the Subversion libraries, i.e. no
third-party code, this issue is virtually restricted to properties and
directories after enabling their deltification in an existing repository.
The chances of the problem to actually manifest are small:

  * Either, there must be node properties > 100kB that changed
    so much that there is a 100kB that has no 64 byte match
    with some earlier version of it.  That would basically
    limit this to non-textual properties.

  * Or, there must be a directory with several 1000 entries
    and each of these must have been touched, added or removed
    over the last 512 revisions (max default delta span).
    Or there were > 1000 entries added at or removed from the
    beginning of the directory to shift the delta window
    sufficiently.

The data is not being corrupted nor is there a known mechanism to corrupt
later commits due to this bug.  A workaround is possible by re-instantiating
the previous version of the node:

  * svn rm /url/of/unreadable/node
  * svn cp /url/of/unreadable/node /url/of/unreadable/node@R-1

or by disabling directory and / or property deltification.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)