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" To: "cygwin AT cygwin DOT com" Date: Thu, 21 Jun 2012 11:05:10 +0200 Subject: RE: RCS file corruption. Message-ID: References:

In-Reply-To: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Content-Transfer-Encoding: 8bit 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