0

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?

  • You could launch a script to compare the old and new folders file by file and tell you where the 800000 bytes are. – Gribouillis Aug 24 '17 at 6:18
  • I have used commands like diff and other apps but nothing is ever shown, do you have any idea what else it mgiht be? – user321627 Aug 24 '17 at 8:18
  • How do you calculate the sizes? It might be because of file system overhead, or skipped empty files/directories. – Magnus Aug 24 '17 at 8:41
  • I just used the Mac Finder Control + I command. Should I do it on terminal instead? – user321627 Aug 24 '17 at 8:42
  • Sorry, I don't know much about mac, and wasn't aware that it was what you were using.. Added the tag now (when it's been reviewed) – Magnus Aug 24 '17 at 9:05
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.