Trying again to send this to dev@apr as they don't accept non-subscriber mail...
Daniel Shahaf wrote on Sun, Feb 05, 2012 at 22:30:31 +0200: > Blair Zajac wrote on Sun, Feb 05, 2012 at 11:35:23 -0800: > > On 02/05/2012 08:08 AM, Daniel Shahaf wrote: > > >stef...@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 > > >>Log: > > >>* STATUS: Add r1240752 and vote for it. > > >> > > >>Modified: > > >> 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: > > > > http://svn.apache.org/viewvc?view=revision&revision=r1044440 > > > > But it's not in any released version of APR, not even 1.4.5: > > > > http://svn.apache.org/repos/asf/apr/apr/tags/1.4.5/file_io/unix/seek.c > > > > Thanks for the pointers. APR 1.4.x@HEAD doesn't have the fix either: > > http://svn.apache.org/repos/asf/apr/apr/branches/1.4.x/file_io/unix/seek.c > > CC'ing dev@apr to request backporting of r1044440. In our use-case > the bug in truncation causes filesystem corruption, i.e., is rather > severe. > > > 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 > file.) > > > > > Blair
