12

When performing a tar on a bz2 compressed file I am encountering the following error,

tar: dump.sql: File shrank by 19573448400 bytes; padding with zeros

Can anyone point what might be causing this issue ?

Thanks.

Iliyas Shirol
  • 235
  • 1
  • 3
  • 6
  • It's year 2021 and also having the same issue (check my question out: https://serverfault.com/questions/1057829/unable-to-compress-18gb-file-on-ubuntu-linux-18-04). Really disappointing. Did you finally solve it? – Claudix Mar 22 '21 at 08:31

3 Answers3

8

It's not an error. It's INFO.

I'm willing to bet you're compressing/decompressing a Virtual Machine image, or otherwise sparsely-allocated file.

Bzip2 has detected that the file is mostly zeroes, and compressed it so that they're not there in the compressed file.

This is the difference between actual size and apparent size of sparse files.

Tom O'Connor
  • 27,440
  • 10
  • 72
  • 148
  • I found a thread that helpfully corroborates and further explains: https://groups.google.com/d/msg/comp.os.linux.misc/RES9Kvw7kO4/i0k5FMSZ3uEJ – Martin Eden Jul 14 '14 at 10:57
  • 2
    If it's not an error, then why does it produce a non-zero exit code? – Ben Collins May 12 '16 at 02:34
  • In my case, the .tar.bz2 file actually contained corrupted data: it contained a bunch of NUL bytes at the location indicated in the message, where it was supposed to contain non-zero data. I have no idea why. When I tried making another .tar.bz2 of just that file, it worked correctly. – 200_success Nov 06 '18 at 04:41
  • 1
    This just happened to me while making a raw tar (not compressed) archive. Definitely not bzip related. And anyway, run length encoding isn't exactly unusual so it's not something bzip would bother reporting. – Wyatt Ward Jan 23 '19 at 03:44
1

The file in question was called dump.sql, so probably not a bz2 compressed file. – In any case, the problem has nothing to do with bz2 or type of content of the file.

The message means, that a stat() on the file reported a different size than the amount which could actually be read from the file. This may happen, if the file was changed while tar was working.

This also happens on “virtual files” like the ones on Linux’ /sys filesystem. Many of them are reported with 4096 Bytes in size (an arbitrary value). Once read(), they only return a couple of bytes.

Robert Siemer
  • 543
  • 9
  • 19
0

Another cause possible is the source file is corrupted by any source disk error.

Another message on these circumstances is: "Cannot stat: Input/output error".

Fabrício Pereira
  • 101