[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 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- dangers of ctrl-z in text files,
Terrence Enger <=