[cvsnt] Re: Alert: Binary files are corrupted when you do a cvs remove

[Matt Schuckmann]

I just tested this with  version 2.5.01 (Travis) Build 1927 and the bug it
is there too.

Tony, any chance that this has been fixed in Build 1949? Any idea when it
did work correctly.

This is the second "bug" I've seen related to binary files and keyword
expansion options in the last month (see  "update -j -kk (was RE: [cvsnt]
Re: Corrupted Word Doc)"  in April )

Matt S.


"Arbesto Pelta" <arbesto_pelta at yahoo.es.remove-it> wrote in message
news:d5qjmk$aa2$1 at paris.nodomain.org...
> Hello,
>
> I am using 2.5.01 Build 1910. I see that the Build 1927 is available
> but I dont see it in the history section and a bad experience with the
> release 2.0.58d did me more careful.
>
> Well, I am experiencing a odd thing: when I do a CVS remove over a binary
> file it is corrupted. Specifically CVSNT substitute in the file ,v all
hexa
> "0a0d"
> sequences by "0a".
>
> The experience:
>
> 1) Before the "cvs remove" all is fine. The file is marked like binary
(and
> the keywords are none) and when I checkout it or take it using viewcvs the
> file is ok.
>
> 2) After I do the "cvs remove" the file is marked equally (binary an
> keywords
> are none) but if I download the previous revisions via viewcvs the file is
> downloaded bad because the "0a0d" sequeneces are substituted by "0a" ones.
>
> 3) I recovered it doing a typical "cvs add" and after it if I try to
> download
> the previous revision via viewcvs or via tortoise but the file is
downloaded
> bad again.
>
> 4) Now I tried to do an update -kb / commit -f process to redo it binay
but
> really this is unsuccessful because really the file ever was binary and
the
> cvs remove didnt change this condition.
>
> 5) Now I compare the ,v files before and after the cvs remove operation
and
> I
> see that the CVSNT has changed the hexa "0a0d" sequences to "0a" ones
inside
> the ,v file... I think that this could do every binary file cvs-removed
> irrecoverable!
>
> Thanks
>
>