You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by st...@apache.org on 2012/02/05 17:03:51 UTC
svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
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
+ has been activated on FSFS repositories, a rep will be truncated from
+ the file after it has been found to be a duplicate of some existing rep.
+ If this happens high up in the tree (in the root folder, preferrably),
+ not enough data may be written afterwards (parant directories + list
+ of changes in that revision) to fully overwrite the stale rep content.
+ Justification:
+ Rare but real source of corruption.
+ Votes:
+ +1: stefan2
+
Veto-blocked changes:
=====================
Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Posted by Daniel Shahaf <da...@elego.de>.
Bojan has merged this to 1.5.x/1.4.x/0.9.x and it'll be included in
1.4.6.
Thanks,
Daniel
Daniel Shahaf wrote on Mon, Feb 06, 2012 at 21:35:34 +0200:
> Bojan Smojver wrote on Mon, Feb 06, 2012 at 09:25:59 +1100:
> > On Sun, 2012-02-05 at 22:44 +0200, Daniel Shahaf wrote:
> > > > > It looks like this was fixed in APR in December 10, 2010 for unix
> > > platforms:
> > > > >
> > > > > http://svn.apache.org/viewvc?view=revision&revision=r1044440
> >
> > If Mladen (the author of the patch) doesn't pick this up and backport,
> > I'll do it tonight. Thanks for pointing it out.
>
> Ping -- "tonight" has passed, but I don't see this backported yet, so
> just making sure it's still queued.
>
> Happy to help if I can.
>
> >
> > --
> > Bojan
> >
Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Posted by Daniel Shahaf <da...@elego.de>.
Bojan has merged this to 1.5.x/1.4.x/0.9.x and it'll be included in
1.4.6.
Thanks,
Daniel
Daniel Shahaf wrote on Mon, Feb 06, 2012 at 21:35:34 +0200:
> Bojan Smojver wrote on Mon, Feb 06, 2012 at 09:25:59 +1100:
> > On Sun, 2012-02-05 at 22:44 +0200, Daniel Shahaf wrote:
> > > > > It looks like this was fixed in APR in December 10, 2010 for unix
> > > platforms:
> > > > >
> > > > > http://svn.apache.org/viewvc?view=revision&revision=r1044440
> >
> > If Mladen (the author of the patch) doesn't pick this up and backport,
> > I'll do it tonight. Thanks for pointing it out.
>
> Ping -- "tonight" has passed, but I don't see this backported yet, so
> just making sure it's still queued.
>
> Happy to help if I can.
>
> >
> > --
> > Bojan
> >
Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Posted by Daniel Shahaf <da...@elego.de>.
Bojan Smojver wrote on Mon, Feb 06, 2012 at 09:25:59 +1100:
> On Sun, 2012-02-05 at 22:44 +0200, Daniel Shahaf wrote:
> > > > It looks like this was fixed in APR in December 10, 2010 for unix
> > platforms:
> > > >
> > > > http://svn.apache.org/viewvc?view=revision&revision=r1044440
>
> If Mladen (the author of the patch) doesn't pick this up and backport,
> I'll do it tonight. Thanks for pointing it out.
Ping -- "tonight" has passed, but I don't see this backported yet, so
just making sure it's still queued.
Happy to help if I can.
>
> --
> Bojan
>
Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Posted by Daniel Shahaf <da...@elego.de>.
Bojan Smojver wrote on Mon, Feb 06, 2012 at 09:25:59 +1100:
> On Sun, 2012-02-05 at 22:44 +0200, Daniel Shahaf wrote:
> > > > It looks like this was fixed in APR in December 10, 2010 for unix
> > platforms:
> > > >
> > > > http://svn.apache.org/viewvc?view=revision&revision=r1044440
>
> If Mladen (the author of the patch) doesn't pick this up and backport,
> I'll do it tonight. Thanks for pointing it out.
Ping -- "tonight" has passed, but I don't see this backported yet, so
just making sure it's still queued.
Happy to help if I can.
>
> --
> Bojan
>
Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Posted by Bojan Smojver <bo...@rexursive.com>.
On Sun, 2012-02-05 at 22:44 +0200, Daniel Shahaf wrote:
> > > It looks like this was fixed in APR in December 10, 2010 for unix
> platforms:
> > >
> > > http://svn.apache.org/viewvc?view=revision&revision=r1044440
If Mladen (the author of the patch) doesn't pick this up and backport,
I'll do it tonight. Thanks for pointing it out.
--
Bojan
Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Posted by Bojan Smojver <bo...@rexursive.com>.
On Sun, 2012-02-05 at 22:44 +0200, Daniel Shahaf wrote:
> > > It looks like this was fixed in APR in December 10, 2010 for unix
> platforms:
> > >
> > > http://svn.apache.org/viewvc?view=revision&revision=r1044440
If Mladen (the author of the patch) doesn't pick this up and backport,
I'll do it tonight. Thanks for pointing it out.
--
Bojan
Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Posted by Daniel Shahaf <da...@elego.de>.
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
Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Posted by Daniel Shahaf <da...@elego.de>.
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
Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Posted by Daniel Shahaf <da...@elego.de>.
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
Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Posted by Blair Zajac <bl...@orcaware.com>.
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
Will an 'svnadmin verify' or 'svnadmin dump' find this corruption? If
one has it, will the standard fsfs repair tool(s) fix it?
Blair
Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Posted by Daniel Shahaf <da...@elego.de>.
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?
Thanks --
Daniel
> + has been activated on FSFS repositories, a rep will be truncated from
> + the file after it has been found to be a duplicate of some existing rep.
> + If this happens high up in the tree (in the root folder, preferrably),
> + not enough data may be written afterwards (parant directories + list
> + of changes in that revision) to fully overwrite the stale rep content.
> + Justification:
> + Rare but real source of corruption.
> + Votes:
> + +1: stefan2
> +
> Veto-blocked changes:
> =====================
>
>
>
Re: svn commit: r1240755 - /subversion/branches/1.7.x/STATUS
Posted by Daniel Shahaf <da...@elego.de>.
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?
Thanks --
Daniel
> + has been activated on FSFS repositories, a rep will be truncated from
> + the file after it has been found to be a duplicate of some existing rep.
> + If this happens high up in the tree (in the root folder, preferrably),
> + not enough data may be written afterwards (parant directories + list
> + of changes in that revision) to fully overwrite the stale rep content.
> + Justification:
> + Rare but real source of corruption.
> + Votes:
> + +1: stefan2
> +
> Veto-blocked changes:
> =====================
>
>
>