My original posting:
-------------------------------------------------------------------------
>>Sparcstation 2 running SUN OS 4.1.1. The files in question
>>have been in existance for quite a while, and the dates of last
>>modification indicate that they have not been modified for over a year.
>>All the files are *.c or *.h variety, and ALL reside in the SAME
>>directory. Many, but not all, of the the files in this directory are
>>the ONLY ones on the system which seem to be affected.
>>
>>Problem:
>>The user has discovered that a few dozen files in question have been
>>truncated. I have looked at them with vi and they do indeed end at
>>random places within each file. The system seems quite happy otherwise,
>>with "fsck" being run a number of times on that disk partition with
>>no complaints.
-------------------------------------------------------------------------
Thanks to the following who responded:
world.std.com!webber (Robert D Webber)
Gregory Higgins <math.niu.edu!higgins>
oce.orst.edu!stanley (John Stanley)
ll.mit.edu!kevinmac (Kevin McElearney)
hasler.ascom.ch!osicki (Osicki Chris)
spatial.com!alek (Alek O. Komarnitsky)
glenn@uunet.UU.NET (Glenn Herteg)
Most of the responses pointed to problems which can occur in certain
circumstances when using 'tar'. Such as the following:
-------------------------------
Use "tar cfb - 8k * | (cd /newdir; tar xfB -)" instead; the B assures
that the receiving tar does reads to get everything in the block
before writing.
-------------------------------
Or if at some point the files were transferrred on top of themselves through
a pipe. One very common way of doing this is by trying to copy files from one
place to another via tar, eg:
tar cvf - . | (cd /somewhere/else; tar xvf -)
Forgetting the 'cd' will cause exactly the problem you have seen. Tar
starts reading the file, gets one block's worth packed up, and sends it
to the receiving tar. The receiver says "I have a file of size X to
write, here is the first part". Since the receiver is now writing the
file, the sending tar sees a change in the file and garbage is sent.
-------------------------------
I also checked for overlapping disk partitions, but that was not a problem.
-------------------------------
Another interesting suggestion (Glenn Herteg):
Perhaps your user tarred the files on a day when the filesystem was
quite full, and tar failed to abort. (There is an "e" option you might
consider using from now on!) Maybe now the space used in this
filesystem has diminished, so no one else is experiencing the same
problem, making it all the more mysterious. Maybe one user was trying
to tar the files at the same time that another user was temporarily
saturating the filesystem, and the second user eventually realized
there was a problem and backed off, deleting lots of files and erasing
all the evidence...why is the "e" option not the default for tar???
-------------------------------
Since the user had periodically used 'tar' on files within this directory
I am assuming that at one time or another one of the above mentioned
errors occurred. We'll be more careful now :-)
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:46 CDT