Why does using 7zip to compress a folder result in different folder file sizes after extraction?

Question

I use 7zip for compression and encrypting folder's I have. However, I noticed recently that, say the folder I wish to compress and encrypt has 29,805,050,333 bytes. Then, I convert the folder into a 7zip archive with encryption.

Then, I unzip this 7zip archive and (am supposed to) get back a second folder with the original contents. However, comparing the original folder to the folder that resulted from extracting the 7zip archive, I see the new extracted folder has 29,805,822,344 bytes.

There is a difference of around 800,000 bytes before and after extracting the folder. What is 7zip doing that causes me to lose these bytes? Is it meta data?

Answer 1

You could be seeing the results of sparse files (looks bigger than the space actually used on disk) being "filled in" by 7zip or the new filesystem, or fragmentation, or indirect blocks, or you're extracting to a different filesystem with different block sizes, thus seeing a different "disk space used" size.

I'm pretty sure mac's have the du utility, it can show you the actual disk space used by files (or a folder path) or just the data size (what archive programs like 7zip compress). Here's some useful options:

--apparent-size
          print  apparent sizes, rather than disk usage; although the apparent
          size is usually smaller, it may be larger due to holes in ('sparse')
          files, internal fragmentation, indirect blocks, and the like

-b, --bytes
          equivalent to '--apparent-size --block-size=1'

-s, --summarize
          display only a total for each argument

So, to see the actual disk space used you'd run

du --block-size=1 -s

But to see just the data size, run

du -b -s 

I also like the -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G) option, but it could obscure smaller differences.

So try running the two different du commands before & after extraction to compare more accurately.