Daniel,
Is your answer based on the knowledge of the code of the subversion server?
Here are some details:
1. It is not Unix [cp(1)], the problem was on Windows
2. The disk looks fine (I ran chkdsk and looked at the SMART data). No
errors in the Windows log files.
3. The svn repository did not change since the problem was detected and I
compared the corrupt hot copy to a correct one. There are 7940 files in
each. Of these, the contents of 28 files are not the same (file sizes are
ok). These 28 files are of various sizes but the first one (2255) is rather
large - 1.5 MB. The repository size is about 1GB. The data in the rev files
of the bad copy is corrupted from positions 0x1000 (first and second file),
0x4000, 0, 0x1000, 0, 0, 0x4000, 0, 0, 0, 0x4000 etc. The corrupted file
numbers are not sequential (2255 corrupted, 2256-2270 ok, 2271 corrupted).
4. Some antivirus software is running on the system.
5. The 'svnadmin hotcopy' which produced the corrupt copy returned 0
(success) to the script that called it.
6. The system might have been heavily loaded at the time the corrupt copy
was made.
It looks unlikely that 28 files were corrupted and no errors were logged by
the OS.
Do you still think is was a disk issue?
Thanks,
Dmitry
PS The server is VisualSVN 2.5.2 (Subversion 1.7.2) on WinXP SP3.
On Wed, Jan 11, 2012 at 6:52 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> D D wrote on Wed, Jan 11, 2012 at 15:51:32 +0400:
> > Once (for now) the verify call failed with 'svnadmin: E160004: Revision
> > file (r2255) lacks trailing newline'
> > The copy of the repository is still available and I can reproduce the
> > problem.
> > The subsequent hot copies of the same repository are ok (for now).
> >
> > Is it ok to file this as a hotcopy bug, please?
> >
>
> No. All 'hotcopy' does is copy the revisions files using the same means
> cp(1) uses. I'd check the health of your disks or replace them.
>
Received on 2012-01-12 10:41:31 CET