[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

dangers of ctrl-z in text files

From: Terrence Enger
Subject: dangers of ctrl-z in text files
Date: Mon, 15 Dec 2003 12:03:05 -0500


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
    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

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

Thank you all for your attention.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]