apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <danie...@elego.de>
Subject Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Date Sun, 05 Feb 2012 20:44:25 GMT
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:
> > >stefan2@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

Mime
View raw message