If I create a 0 block sparse file and then rsync it, it's not 0 blocks on the copy. Here's a reproducer: $ rsync --version rsync version 3.0.7 protocol version 30 Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. $ dd if=/dev/zero of=/tmp/sparse_file bs=1M count=0 seek=5 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.000125157 s, 0.0 kB/s $ ls -ls /tmp/sparse_file 0 -rw-r--r-- 1 brian brian 5242880 2010-04-08 10:33 /tmp/sparse_file $ rsync --sparse /tmp/sparse_file /var/tmp $ ls -ls /var/tmp/sparse_file 12 -rw-r--r-- 1 brian brian 5242880 2010-04-08 10:34 /var/tmp/sparse_file Notice the source file is 0 blocks long and the destination is 12 blocks long. Gnutar on the other hand makes the destination as sparse as the source: $ tar CcSvf /tmp - sparse_file | tar Cxvf /var/tmp/ - sparse_file sparse_file $ ls -ls /var/tmp/sparse_file 0 -rw-r--r-- 1 brian brian 5242880 2010-04-08 10:33 /var/tmp/sparse_file
Rsync currently writes out a 0-byte into the final byte of the file when a file is sparse clear through to the end. We should probably change that to use ftruncate() (when available) instead. I'll give that a try soon, unless someone beats me to the punch.
You might want to use "du" to see how much space a file spends. It is 0 for both source and destination files. Or did I miss something?
As long as the extra space was caused by the final block getting allocated when it shouldn't have been, this should now be fixed in git. If the file's real blocksize vs its rsync blocksize caused some unallocated blocks to not get found, that is not something that can be easily fixed.