Hi there,
I stumbled upon an apparent bug in tar the other day, and thought I
would share a patch fixing the bug, although the bug probably seldom
occour with ordinary usage of tar.
Thing is, I accidently tar'ed my /sys directory while backing up an
entire machine. This naturally caused lots "File shrank by xxxx bytes;
padding with zeros" since the files in /sys are reported as 4KB although
they are smaller. Later, when I attempted to untar the archive,
everything following the first shrunk file wasn't untar'ed. Analysing
the tar file, I found that the shrunk files which was reported as 4KB in
the file header, actually used 8KB in the tar file.
Debugging tar proved that the file was actually padded twice. First by
the line
set_next_block_after (blk + (bufsize - 1) / BLOCKSIZE);
which moves the current_block pointer regardless of whether we actually
got all the bytes requested by the safe_read function. Then, it detects
that count (the actual number of read bytes) is less that bufsize, and
the file is padded with the remainding bytes (cambered to BLOCKSIZE).
Finally the function terminates with dump_status_short.
I found that moving the set_next_block_after after the "count !=
buffsize" did the trick.
I've attached a patch for tar-1.15.1
Best Regards
Peter Christensen
------------------------------------------------------------------------
diff -Nru tar-1.15.1.old/src/create.c tar-1.15.1.new/src/create.c
--- tar-1.15.1.old/src/create.c 2004-10-04 11:21:31.000000000 +0200
+++ tar-1.15.1.new/src/create.c 2005-09-12 22:22:42.074928712 +0200
@@ -874,8 +874,6 @@
}
size_left -= count;
- set_next_block_after (blk + (bufsize - 1) / BLOCKSIZE);
-
if (count != bufsize)
{
char buf[UINTMAX_STRSIZE_BOUND];
@@ -891,6 +889,9 @@
pad_archive (size_left);
return dump_status_short;
}
+
+ set_next_block_after (blk + (bufsize - 1) / BLOCKSIZE);
+
}
return dump_status_ok;
}