delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2012/06/21/05:05:46

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,TW_TD
X-Spam-Check-By: sourceware.org
Received-SPF: Fail (mail7.getronics.com: domain of Peter DOT Wagemans AT getronics DOT com does not designate 158.67.12.30 as permitted sender) identity=mailfrom; client-ip=158.67.12.30; receiver=mail7.getronics.com; envelope-from="Peter DOT Wagemans AT getronics DOT com"; x-sender="Peter DOT Wagemans AT getronics DOT com"; x-conformance=spf_only; x-record-type="v=spf1"
Received-SPF: None (mail7.getronics.com: no sender authenticity information available from domain of postmaster AT EXCNLDCH02 DOT europe DOT unity) identity=helo; client-ip=158.67.12.30; receiver=mail7.getronics.com; envelope-from="Peter DOT Wagemans AT getronics DOT com"; x-sender="postmaster AT EXCNLDCH02 DOT europe DOT unity"; x-conformance=spf_only
From: "Wagemans, Peter" <peter DOT wagemans AT kpn DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Date: Thu, 21 Jun 2012 11:05:10 +0200
Subject: RE: RCS file corruption.
Message-ID: <B7EEF3066CD1D24081DBFF5E9F5E68D4C17C1D97@EXCNLDCM06.europe.unity>
References: <B7EEF3066CD1D24081DBFF5E9F5E68D4C17C1696 AT EXCNLDCM06 DOT europe DOT unity> <CAD+0NRC-noW0-LxEjO_sCtP7SKdSWbaPoJU3zTwOs-pOMknkLg AT mail DOT gmail DOT com>
In-Reply-To: <CAD+0NRC-noW0-LxEjO_sCtP7SKdSWbaPoJU3zTwOs-pOMknkLg@mail.gmail.com>
MIME-Version: 1.0
X-IsSubscribed: yes
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
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id q5L95hVH016813

Richard Gribble wrote:

> I have experienced this problem several times.  In my case it seemed
> to be a problem between 'Unix' and 'DOS' files.  In each case, I
> have been able to fix it by editing the RCS file using vim and
> deleting all the extraneous carriage returns

RCS should be able to handle carriage returns without problems and
indeed, my Linux build of the same code works correctly on the example
files.

In this case at some point the RCS code copies the work file content
to the new RCS file as the latest version and unexpectedly gets an EOF
after exactly 65536 bytes.  

[The file copy loop is the code under "/* Copy the file.  */" in
putdftext in rcsgen.c in the GNU rcs 5.8.1 code. At the lowest level
in the RCS code the EOF comes from the getc(stream) in the
GETBYTE_BODY macro used in the function fro_try_getbyte in b-fro.c.]

But you may be on to something with the carriage returns. In my
example file there is a carriage return linefeed pair just on the 64kB
boundary:

Output from od -t x1z -Ad:

0065520 78 20 78 78 20 78 78 78 78 78 78 78 78 78 2e 0d  >x xx xxxxxxxxx..<
0065536 0a 0d 0a 2a 2a 2a 2a 2a 2a 20 78 78 78 78 78 78  >...****** xxxxxx<

Perhaps this is not a coincidence. It makes me wonder whether some
underlying layer is seeing the carriage return at the end of the
buffer, looks ahead for a linefeed (data that is not available in the
current buffer) and causes the EOF in some way.

How can we find out why getc is incorrectly returning EOF in this
situation?

Regards,

Peter Wagemans


--
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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019