Blair Zajac wrote on Sun, Feb 05, 2012 at 11:35:23 -0800:
> On 02/05/2012 08:08 AM, Daniel Shahaf wrote:
> >stefan2_at_apache.org wrote on Sun, Feb 05, 2012 at 16:03:51 -0000:
> >>Author: stefan2
> >>Date: Sun Feb 5 16:03:51 2012
> >>New Revision: 1240755
> >>URL: http://svn.apache.org/viewvc?rev=1240755&view=rev
> >>* STATUS: Add r1240752 and vote for it.
> >> subversion/branches/1.7.x/STATUS
> >>Modified: subversion/branches/1.7.x/STATUS
> >>URL: http://svn.apache.org/viewvc/subversion/branches/1.7.x/STATUS?rev=1240755&r1=1240754&r2=1240755&view=diff
> >>--- subversion/branches/1.7.x/STATUS (original)
> >>+++ subversion/branches/1.7.x/STATUS Sun Feb 5 16:03:51 2012
> >>@@ -84,6 +84,18 @@ Candidate changes:
> >> Votes:
> >> +1: rhuijben, philip
> >>+ * r1240752
> >>+ Workround for a faulty APR truncate() implementation. When rep sharing
> >A bit more info please? What APR platforms/versions are affected?
> It looks like this was fixed in APR in December 10, 2010 for unix platforms:
> But it's not in any released version of APR, not even 1.4.5:
Thanks for the pointers. APR 1.4.x_at_HEAD doesn't have the fix either:
CC'ing dev_at_apr to request backporting of r1044440. In our use-case
the bug in truncation causes filesystem corruption, i.e., is rather
> Will an 'svnadmin verify' or 'svnadmin dump' find this corruption?
> If one has it, will the standard fsfs repair tool(s) fix it?
Any attempt to read the revision (even with 'svn') should fail pretty
quickly. (Reading a revision file starts by reading the root noderev's
offset and the changed-paths offset from the last line; that last line
is likely to either be garbage or point at garbage offsets within the
Received on 2012-02-05 21:31:20 CET