X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED
X-Spam-Check-By:	sourceware.org
From:	"Wagemans, Peter" <peter DOT wagemans AT kpn DOT com>
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Date:	Wed, 26 Sep 2012 17:46:45 +0200
Subject:	RE: [ANNOUNCEMENT] Updated: rcs-5.8.1-1: The Revision Control System
Message-ID:	<B7EEF3066CD1D24081DBFF5E9F5E68D4C74498A2@EXCNLDCM06.europe.unity>
References:	<announce DOT 87obl46fbi DOT fsf AT oracle DOT com>
In-Reply-To:	<announce.87obl46fbi.fsf@oracle.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 base64 to 8bit by delorie.com id q8QFl8FL016857

Dear Dr. Zell,

> [ANNOUNCEMENT] Updated: rcs-5.8.1-1: The Revision Control System

Do you perhaps know whether this version fixes the file corruption
problem noticed earlier on this list for 5.8, or should we stay with
5.7 to avoid corrupting large RCS files?

Short problem description (what I think is happening):

For large files, the check-in tool ci decides to do file descriptor IO
instead of memory mapped IO.

Ci reads the start of the work file. This triggers the IO library to
fill its buffer, 64k in this case.

Ci dups the file descriptor and supplies it to a diff subprocess. The
file pointer is shared.

Diff reads the entire file. This places the file pointer at the end of
the file.

Ci rewinds the work file. The IO library sees that the start of file
position is in the current buffer and simply resets the buffer
pointer.

Ci wants to read the entire work file to place it in the new rcs
file. At the end of the 64k buffer, the IO library reads the file
descriptor for the next 64k.  But the file pointer of the file
descriptor is still at the end of the file, so ci gets an EOF and
thinks the work file copy is complete.

Thus the content of the last version in the rcs file is truncated to
64k and the rcs file most likely becomes inconsistent, since the edit
scripts to reproduce older versions from the last version refer to
lines that are no longer present.

If you do a check-in, check-out sequence, then you end up with a
truncated work file, corrupted rcs file, have lost recent work and
must resort to backups.

Regards,

Peter Wagemans

- Raw text -