dangers of ctrl-z in text files

[Terrence Enger]

Greetings.

In a recent posting to info-cvs, I pointed out the need to
flag as binary any file which might contain a byte with the
value decimal 26, a.k.a. ctrl-z.  Then I sat down to write
some words for chapter 9 of the Cederqvist, and I find that
I still have a little bit<grin/> to learn.  Can somebody
help me with these questions?

(*) I have just demonstrated the problem using 
        Client: Concurrent Versions System (CVS) 1.11.4
        (client)
    running under Windows ME.  Can you tell me how other
    clients behave in this respect?  Do references to other
    clients belong in the Cederqvist, anyway?

(*) I know about ctrl-z marking end-of-file on Microsoft
    operating systems.  Are there other operating systems
    having this or a similar dangerous feature?

(*) Does cvs server on a MS operating system have the same
    problem with the repository files?

(*) Where should the new paragraph go within Chapter 9:
      - Early (second paragraph) in 9.1 "The issues with
        binary files", because getting your data back is a
        really basic function?
      - Last in 9.1, because only people using or targeting
        a Microsoft operating system care.

(*) Here are the "some words" so far.  I invite comments.

        The most basic function of a version control system
        is the ability to retrieve the files that the user
        puts into the system.  Users importing [Terry: 
        demonstrate this] or committing binary files from 
        a client running on a Microsoft operating system 
        may fail to get their data into the repository if
        they forget to flag a binary file as binary.  The
        problem arises when you put into the repository a
        file containing a byte value of ctrl-z or 26
        decimal.  Reading this file in text mode, cvs sees
        that byte as an end-of-file marker; any following
        data does not go into the repository.  The problem
        is particularly pernicious as both the checkin and
        checkout execute without any indication of a
        problem.  Perhaps only the attempt actually to use
        the file will reveal that data has been lost.


On the other hand, is there a program change we could make
to mitigate the problem?

(*) If a checkout gives a file like it was checked in on the
    same platform (the ctrl-z, following data, and the same
    length in the directory entry), it would be hard to say
    that the behaviour is wrong.  Could there by anybody
    relying on the old behaviour?

(*) Could we give a message for a "damaged" checkin?  What
    severity?

(*) Is it possible to accomplish either of these without
    adding undesirable platform-specific code to cvs?


Thank you all for your attention.

Terry.