Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
I have received a tar archive from a co-worker and after decompresing I found that some text files are corrupted. More precisely they are filled with zeros. They have correct size but all bytes are equal to 0x00.
Can this situation be caused by some uncompatibility of tar versions or eg. chinese character contained in the files or the files had to been corrupted in the time of compression? I do not expect that there was a problem during transfer because control checksum is OK.
Are you sure all bytes are equal to 0x00? In that case your files contain no information at all (except for their size). No program could possibly store or transmit information as all zeros (unless it's telepathic).
What can happen is that a file has alternating text and zero bytes. Here's what this would mean: You've received files that contain unicode text, encoded as UTF-16 (or a near-equivalent). Each character takes up 16 bits (two bytes). Unicode assigns English letters and symbols to their ASCII character code, which means that, for example, letter A is hex 41 in ASCII and 00 41 in Unicode. The result is that if you write out "Hello" as UTF-16 and read it in as 8-bit text, you'll see this:
\0 H \0 e \0 l \0 l \0 o
In that case it wouldn't be the fault of tar. But if you really received all-zero files and the checksums check, there is definitely something wrong with the creating program. Not a version problem, but who knows? Perhaps a hardware problem causing the generating program to read all zeros.
(It's also possible, of course, that the files were correctly archived, and the bug is in the program that created the archived files).
Telepathic ARchiver ... or short TAR ... it ought to know!
Mar 4, 2013 at 14:56
The most likely problem is that the tar got corrupted while it was being created. Due to the way the tar format is defined (since it is intended to be a streaming archiver) it must determine the file length ahead of time. It records this length in the tar header, then starts writing the file contents to the tar file. If for some reason there is an error reading the file, or if the file shrinks while it is being archived, it will fill in NULLs. This is needed so that the length specified in the header is still valid upon extraction (it can't go back and modify the header due to its streaming nature, and if it didn't pad the file with NULLs that would cause an error when extracting the next file in the archive).
Also, since tar deals with binary data (it has no "text" mode), there shouldn't be any issue (as far as tar is concerned) with different language encodings.
cp refused to copy the files from the SD card (citing an I/O error), but tar happily appeared to tar the files. I guess tar is too fault tolerant and created the tar file, even though it was useless, since all extracted files were pure 0, confirmed with od -t x1 files*.
Jan 12, 2018 at 0:02
tar tf the-archive.tar | sort | uniq -dreport anything by any chance? (what abouttar tvf the-archive.tar | grep -v '^[ld-]')? What the operating system and tar version and file system where the tar file was made and where it is extracted?