X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=IsiuWWN
	Zn+1Tmyrrc8NnSp+19KqOxvmIuewyKj83oQYSDjFQVprQhYsT7a2UgyO1+53k2sq
	KMmOVq1IqRn2BzNKTQLJbJy2sM0ptVPvT8nK3Umc1RKYnoSTQR4Pik1o33NaMTJT
	ooDCw5uRQmr0u84Md+CAIV6yeCfFQkvKJXQg=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=0Qat9Qi8lRHRB
	0jwcafrQKHlkO0=; b=QZ1gGkc57wuATftUlzh/RW4q5e1x0I+bzYPzbU5PixMtY
	U4MapiYyh3uGWGKDCIDbq744o0TRyGNc/6x929GcyLwpzJgGXTqZWqNLR/UikEJq
	mLOFwgP1i8933cqL5yUOIotnhG/3F6wjL+ElTCujOf3Mh65KOVo+fLY5BHx9TA=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.2 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2
X-HELO:	mail-vc0-f182.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=IjZr+QF6zl6D4xDv2ZfIjuqSuVl94UCKjsLsbdED5zM=; b=MGSY+QLPGvqMY+49hTvmrrOZMVxvKAy4IOVzRPSt5i+LHJ5VAChva7+QixmTFyf01j 4Q9yJmQ2PQnyME8NUJQNo3ftLnMISaN+qelDnGXMXil9jyZUcrUZofE0LSm/reuDB/JY B03RNgY3t7qpylU4YawgrmiH2NcUzeczuI6sR14/7o19enf+JMmkWO/35hn/TL18Cr6p Fjmb63JFNwZKGgxtBDBAvf1EVRoIQU/Zy5G7EELO457qABgkxZO+sS0ELYJp8I21Hud/ m4f7an3hVSApvcUahF3Ws3UNFYfBnvh+XGvDx0jnBa+c0RfeZjNsWjS+DpM+pLwqMeyy iWMQ==
X-Gm-Message-State:	ALoCoQnSSLLojSOlQcFRzCTrY0HgpqZ8cuWLMklCwQDD1DTzXd0fvxYr4kYSuBWPD5RNZHo+ilgI
X-Received:	by 10.220.237.208 with SMTP id kp16mr7657941vcb.4.1381352249474; Wed, 09 Oct 2013 13:57:29 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<87ppreqoxq.fsf@Rainer.invalid>
References:	<20131008102204 DOT GB9241 AT plunk DOT org> <525499E5 DOT 4090608 AT etr-usa DOT com> <52555E65 DOT 1070000 AT cs DOT utoronto DOT ca> <87ppreqoxq DOT fsf AT Rainer DOT invalid>
From:	Richard Gribble <richard AT gandalfwizard DOT us>
Date:	Wed, 9 Oct 2013 16:56:49 -0400
Message-ID:	<CAD+0NRCEXHzr5DNUXr1YA2dnbeUYsriTjNxH-RJVWNeCrCcuAQ@mail.gmail.com>
Subject:	Re: checking in >= 256k file fatally corrupts rcs file
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

I

On Wed, Oct 9, 2013 at 2:28 PM, Achim Gratz <Stromeko AT nexgo DOT de> wrote:
> Ryan Johnson writes:
>> So in other words, a misguided performance optimization [1] that
>> almost certainly has little measurable impact on performance [2] has
>> introduced a silent data corruption bug (or tickled a latent one
>> somewhere else). Lovely.
>
> It is not the performance optimization that isn't working, but the code
> path through plain stdio while doing a diff that was probably never
> exercised (the tests all pass on Cygwin).  Try RCS_MEM_LIMIT=0 to force
> stdio.  The error does not occur on Linux and it doesn't seem to be
> known to the devs.
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> Wavetables for the Waldorf Blofeld:
> http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
>
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

I can attest to the problem with file size corrupting the file - on
several occasions I have checked in a file and lost roughly half of
it.  As RCS only stores the last version in its entirety and deltas
against that version to create prior versions, losing part of the
current version results in a completely corrupt file - the only thing
that has saved me is that I have two copies of RCS on separate
computers.  I now only check files in on my Linux box, then transfer
them to the Windows/cygwin box.

However, by the same token, there is a bug in 5.7 where the check of
the symbolic name (when checking out a file) only tests the number of
characters in the table of symbolic names - for example, say you have
a file with the following symbolic names:  R25, R25a, R25b, R25c and
R26.  Now you try to check out version R25c.  If the code finds the
R25 symbolic name first (before R25a/R25b/R25c), it compares three
characters (the length of "R25") against the first three characters of
the symbolic name provided to the co command ("R25") and finds a match
- giving you the wrong version.  So neither option is ideal.


Respectfully,

Richard Gribble.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -