[cvsnt] BUG: Corrupted binary files

Bo Berglund Bo.Berglund at system3r.se
Wed Jun 15 10:15:52 BST 2005


Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.


If at any time you had the CVSNT server running a version of cvs.exe that
had the binary file corruption problem (between an unknown 2.0.62 build
and an unknown test release build of 2.5.01) and at that time you did a
commit operation on the binary file, then you have lost contents in the
file and I don't think there is an easy way out except getting the backup
out from your tape archive (from before the problem happened). :-(

/Bo


-----Original Message-----
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org]On Behalf
Of Kevin
Sent: den 15 juni 2005 10:55
To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
Subject: Re: [cvsnt] BUG: Corrupted binary files


> Just do it on a copy of the repository on your test server, or just on a
> local machine somewhere... take a file that's known to work and try to
> break it.
>

Tony,

I tried to regenerate the problem on a fresh test repo. I tried out a lot of
merges and branches and removed the HEAD revision. This did not reproduce
the problem.

Afterwards I even tried to regenerate the scenario from the graph of a
problematic file (on the test repo). The was not successful as the file in
question has been around for a few years and has seen *older* CVSNT versions
(the ones that committed mergepoints always, even when there were no changes
made to the file). So again this was all futile.

Please appreciate that we have been using CVSNT for over 2 years now and are
relying heavily on it. Presently we have files that are corrupted. The worse
part is that we cannot correct the situation as committing the *correct*
binaries is not placing a correct version at the tip of the branch. We are
now not sure as to whether we can trust the contents of the repository any
more. Is there anything that can be done about this issue? Being able to fix
the files on the repository is an adequate enough solution. Force committing
the file (-f) does not work either.

May I once again point out that I can submit a problematic RCS file to help
in finding a solution.

-- 
Kevin Agius

"Tony Hoyle" <tmh at nodomain.org> wrote in message
news:d8mf70$3cp$1 at paris.nodomain.org...
> Kevin wrote:
> > 1) I would not like to lose the file's tags, branches, etc. This would
have
> > a very negative impact if we need to extract older revisions. Presently
we
> > have broken branches and these are enough of a headache. We are using
CVSNT
> > on a production environment and cannot take risks.
>
> > 2) How do I produce a script?
>
> A sequence of commands to reproduce the problem is enough.
>
> > 3) Is build 1969 recent enough? It is the latest stable release. I did
not
> > manage to find build 1927 in the history page, the one that started all
the
> > mischief.
>
> Yes it should be.
>
> Tony


_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook