RCS file corruption.

Wagemans, Peter peter.wagemans@kpn.com
Tue Jun 19 13:18:00 GMT 2012


For many years I have been using Emacs and RCS version control for
individual simple notes and org-mode text files, with a habit of
frequent check-in and check-out to save units of work. On Windows the
RCS implementation is from Cygwin.

Over the last months I have encountered several cases where check-in,
check-out resulted in a work file truncated at exactly 64kiB and an
inconsistent RCS file. Recovery from backup was necessary. Since both
files were destroyed, I was unable to reproduce the problem.

Now I seem to have found an example with a reconstructed work file
that seems to systematically show the error (on my system) when
checked in to an older backup RCS file.

Problem aspects:

 - The check-in reduces the size of the RCS file. It maintains the
   version history and delta scripts, but the content of the latest
   version is truncated to 64kiB (in the cases I encountered). [The
   size of the latest version as stored within the RCS file is a bit
   bigger since '@'-characters are doubled.]

 - This makes the RCS file inconsistent: the edit scripts to recreate
   older versions refer to line numbers that no longer exist.

 - Since the problem also occurs on the command line, Emacs is not
   part of the problem, just the way I encountered it.

 - In my problem cases, the RCS files were not very small, up to
   several MiB in size, usually also with modifications "in the
   middle", not just extra content at the end. This is just for
   information; I have no evidence whether any of this is relevant to
   the problem.

 - On Windows 7 64-bit and Vista 32-bit, I have seen the problem with
   Cygwin rcs-5.8-1, so far not with rcs-5.7-11 (switching back and
   forth several times with Cygwin setup.exe).

 - On the example files, the GNU rcs 5.8.1 distribution compiled on
   OpenSuSE 11.4 64-bit does the check-in OK. The same code base
   configured and built on Windows 7, 64-bit under Cygwin produces an
   inconsistent RCS file upon check-in. So it is probably not a pure
   RCS bug; it seems dependent on the Cygwin environment.

Attached is an archive with a template directory with a checked out
work file and two directories after check-in, one successful (rcs
package 5.7-11) and one not (rcs package 5.8-1). To reproduce the
problem, copy the template directory tree, place your user name in the
lock section of the RCS file blind.org,v:

	xxxxxxxxx:1.100; strict;

instead of 'xxxxxxxxx' and then do a check-in with ci.

The attached cygcheck output is for Windows 7 64-bit, edited for
confidentiality. 

Alphanumeric content characters in the example files have been
replaced with the character 'x'.

Now I'm wondering how to proceed with this problem (apart from
reverting to rcs 5.7):

 - Have other people encountered this kind of problem?

 - Can other people reproduce the problem with my example file?

 - Is there a known solution?

 - If not, how can the problem be tracked down and solved?


Regards,

Peter Wagemans

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygcheck.out_201206181741_edited
Type: application/octet-stream
Size: 275170 bytes
Desc: cygcheck.out_201206181741_edited
URL: <http://cygwin.com/pipermail/cygwin/attachments/20120619/b3889d68/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rcs_corruption_example.tar.gz
Type: application/x-gzip
Size: 434050 bytes
Desc: rcs_corruption_example.tar.gz
URL: <http://cygwin.com/pipermail/cygwin/attachments/20120619/b3889d68/attachment.bin>
-------------- next part --------------
--
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


More information about the Cygwin mailing list