RE: RCS file corruption.

["Wagemans, Peter" <peter dot wagemans at kpn dot com>]

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