On Fri, Dec 16, 2005 at 07:54:24PM -0500, John Szakmeister wrote:
> Sorry I've been so quiet lately... I've had some pretty tough hours at work
> lately.
Don't worry - I've been pretty busy at work and home lately, so I've
not been much use either. (And I'm off on holiday tomorrow morning --
all packed now! -- so I'll be out of the country for the next two weeks
anyway .. without a laptop).
> I did manage to spend some time and take a look at those other
> corrupted rev files. Your analysis is right on the mark for those files as
> well. You can definitely see that the number of bytes overwritten is what
> would have been left in a 4K buffer.
Ah, good. At least we only seem to be looking at one problem.
> I'm not sure where to proceed though.
I'm not entirely clear how to do it yet, but I'd like to make it
impossible (or at least, very hard) for this problem to occur in the
FSFS library, regardless of the behaviour of the caller. Specifically,
I'd like to either make sure we hold open the proto-rev file throughout
the life of the transaction, or if that's too hard, ensure that each
APR file handle is destroyed before we return to the caller.
I'd also like to consider whether it's worth validating the proto-rev
file before we move it into place. Unfortunately, the FSFS rev-file
layout isn't very suitable for that: you can't read the rev-file through
from start to finish (or at least, I don't think you can).
Finally, I'd like to fix the broken caller, of course.
> I did see a suspicious looking bit of code in mod_dav_svn:is_our_resource()
> where we attempt to coalesce some handles together but completely ignore all
> errors.
Yes, I saw that. I'd just like to reiterate that APR < 0.9.7 doesn't
report write errors for buffered files at all, which I strongly suspect
is part of this problem.
> I haven't had much time lately to look into mod_dav_svn any further
> though. At this point, it'll be sometime after the New Year before I get a
> chance to really do a thorough audit of that code.
Sure, no worries. I'm not really in a position to do much with
mod_dav_svn, so I'm probably going to focus on the filesystem-side.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 27 01:54:34 2005