[
https://issues.apache.org/jira/browse/SVN-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Kotkov resolved SVN-4658.
--------------------------------
Resolution: Fixed
Fix Version/s: 1.8.17
1.9.5
Fix for this issue was included in Subversion 1.9.5 and 1.8.17.
> 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
> Fix For: trunk, 1.9.5, 1.8.17
>
>
> 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)