From: faith@cs.unc.edu (Rik Faith) Subject: FOLLOWUP: fileutl-3.3B* and find-3.7B*: possible problems Date: 28 Jul 1992 17:39:58 GMT
This note explains the problems that I was having with fu-3.3's cp, what
caused these problems, and why cp is really *SAFE*!
The only documented problem with fu-3.3's cp involves cp'ing a kernal image
for booting with shoelace (i.e., cp Image /vmunix). The cp in 3.3, since I
compiled it with a kernel that has st_blocks working correctly (i.e., 0.96c
pl2) is now able to detect when a file has "holes" in it. It will then try
to copy the "holes." It does this during the copy by looking for a block of
zeros, and when finding such a block, using an lseek() to move past the block
[*instead* of a write()]. [This is information is from an examination of the
GNU source.] The filesystem is apparently smart enough to *not* allocate a
block for these zero's, thereby storing the file more efficiently.
However, shoelace *CANNOT* correctly read a file that contains "holes."
So, I had two *IDENTICAL* kernel images, one created with a new cp and one
created with an old cp. They were identical in terms of size, sum, and diff.
One would boot and the other would not. This seemed very weird, and since
a new utility that I has posted was involved, I decided to err on the side
of caution and post a retraction message (especially since I had made some
optimizations in the compilation of the posted binaries). It now seems that
this was not necessary, and that the files that I posted are *SAFE*.
Sorry for the confusion.
When 2.2.2d gets released, I'll be posting new compilations. In the mean
time, the old (and new) versions are available from
ftp.cs.unc.edu:/pub/faith/uploads. I won't bother putting these on tsx-11
or on banjo again unless there is some demand.
-- Rik Faith: faith@cs.unc.edu