You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Paul E <pa...@gmail.com> on 2013/01/10 21:11:04 UTC
Truncated file issues
Hi,
We're having an issue that has occurred three times in the past two weeks
with two different repositories hosted with VisualSVN (version 2.5.8).
Upon checkout, we get the following message:
REPORT of '/svn/<project>/!svn/me': Could not read chunk size: Secure
connection truncated
Apache logs show:
[Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] A failure
occurred while driving the update report editor [500, #70014]
[Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] Can't read file
'E:\\<SVNPath>\\<Project>\\db\\revs\\0\\135': End of file found [500,
#70014]
svnadmin verify returns:
* Verified revision 135.
svnadmin: E070014: Can't read file 'E:\<SVNPath>\<Project>\db\revs\0\135':
End of file found
This is a major issue for us as we're actively developing against these
projects and having to recommit over and over again. Currently resolving
the issue by creating a dump to the revision prior to the truncation and
then loading into a new repository, but this is costing development time.
Thanks for advance for your help.
Paul
Re: Truncated file issues
Posted by Paul E <pa...@gmail.com>.
Apologies, I failed to mention that I had upgraded VisualSVN Server from
2.5.6 to 2.5.8 after the first repository exhibited corruption. I have not
tried VisualSVN 2.5.7.
I have looked into potential hardware issues, but am fairly confident
that's not the issue. This is fully redundant server with a RAID drive
configuration and hardware tests are all checking out.
For further specifications, this is a 64-bit Windows 2008 R2 machine.
On Fri, Jan 11, 2013 at 11:37 AM, Stefan Sperling <st...@apache.org> wrote:
> On Thu, Jan 10, 2013 at 02:11:04PM -0600, Paul E wrote:
> > Hi,
> >
> > We're having an issue that has occurred three times in the past two weeks
> > with two different repositories hosted with VisualSVN (version 2.5.8).
>
> VisualSVN 2.5.8 is pretty recent. Did this start happening after an
> upgrade/install of 2.5.8? Have you tried downgrading to 2.5.7 to see
> if that fixes the issue?
>
> VisualSVN 2.5.8 includes Subversion 1.7.8, which has the following change
> in the FSFS filesystem code:
> * fix fs_fs to cleanup after failed rep transmission (r1403964, et al)
>
> Maybe what you are seeing is a regression introduced with that fix?
>
> Please confirm if possible. Thanks!
>
> BTW, a similar issue has been reported here:
> http://svn.haxx.se/users/archive-2013-01/0029.shtml
>
> > Upon checkout, we get the following message:
> >
> > REPORT of '/svn/<project>/!svn/me': Could not read chunk size: Secure
> > connection truncated
> >
> > Apache logs show:
> >
> > [Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] A failure
> > occurred while driving the update report editor [500, #70014]
> > [Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] Can't read
> file
> > 'E:\\<SVNPath>\\<Project>\\db\\revs\\0\\135': End of file found [500,
> > #70014]
> >
> > svnadmin verify returns:
> >
> > * Verified revision 135.
> > svnadmin: E070014: Can't read file
> 'E:\<SVNPath>\<Project>\db\revs\0\135':
> > End of file found
> >
> > This is a major issue for us as we're actively developing against these
> > projects and having to recommit over and over again. Currently resolving
> > the issue by creating a dump to the revision prior to the truncation and
> > then loading into a new repository, but this is costing development time.
> >
> > Thanks for advance for your help.
> >
> > Paul
>
Re: Truncated file issues
Posted by Stefan Sperling <st...@apache.org>.
On Thu, Jan 10, 2013 at 02:11:04PM -0600, Paul E wrote:
> Hi,
>
> We're having an issue that has occurred three times in the past two weeks
> with two different repositories hosted with VisualSVN (version 2.5.8).
VisualSVN 2.5.8 is pretty recent. Did this start happening after an
upgrade/install of 2.5.8? Have you tried downgrading to 2.5.7 to see
if that fixes the issue?
VisualSVN 2.5.8 includes Subversion 1.7.8, which has the following change
in the FSFS filesystem code:
* fix fs_fs to cleanup after failed rep transmission (r1403964, et al)
Maybe what you are seeing is a regression introduced with that fix?
Please confirm if possible. Thanks!
BTW, a similar issue has been reported here:
http://svn.haxx.se/users/archive-2013-01/0029.shtml
> Upon checkout, we get the following message:
>
> REPORT of '/svn/<project>/!svn/me': Could not read chunk size: Secure
> connection truncated
>
> Apache logs show:
>
> [Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] A failure
> occurred while driving the update report editor [500, #70014]
> [Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] Can't read file
> 'E:\\<SVNPath>\\<Project>\\db\\revs\\0\\135': End of file found [500,
> #70014]
>
> svnadmin verify returns:
>
> * Verified revision 135.
> svnadmin: E070014: Can't read file 'E:\<SVNPath>\<Project>\db\revs\0\135':
> End of file found
>
> This is a major issue for us as we're actively developing against these
> projects and having to recommit over and over again. Currently resolving
> the issue by creating a dump to the revision prior to the truncation and
> then loading into a new repository, but this is costing development time.
>
> Thanks for advance for your help.
>
> Paul
Re: Truncated file issues
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Paul E,
am Donnerstag, 10. Januar 2013 um 21:11 schrieben Sie:
> This is a major issue for us as we're actively developing against
> these projects and having to recommit over and over again. Currently
> resolving the issue by creating a dump to the revision prior to the
> truncation and then loading into a new repository, but this is costing development time.
Something is corrupting your repository, but your on your own to find
the problem. From what I've read it's most likely a hardware or OS
problem, for example your filesystem may be corrupted. I had similar
issues some years ago with a virtualized Windows where for some reason
the filesystem broke two times in one weak and the only solution was
to create a new file system and restore into this from backup. Have a
look at your event viewer, do checkdisk, maybe even memory tests, you
can even try to monitor disk access with Process Monitor form
Sysinternals to see if something occurs.
But first of all I would implement a good backup process, e.g. using
svnsync and hooks or something similar, as it doesn't sound you are
prepared for loss of revision files.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Truncated file issues
Posted by Philip Martin <ph...@wandisco.com>.
Paul E <pa...@gmail.com> writes:
> * Verified revision 135.
> svnadmin: E070014: Can't read file 'E:\<SVNPath>\<Project>\db\revs\0\135':
> End of file found
This looks like a rep-caching bug: r136 is using the wrong offset into
r135. It appears to be issue 4277 although I'm not aware of anyone ever
triggering it before:
http://subversion.tigris.org/issues/show_bug.cgi?id=4277
If you are seeing this repeatedly then you could disable rep-caching in
db/fsfsf.conf.
Have you ever done any manual editing of the repository files? Or
copied the revision files or rep-cache.db separately?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download