Why do 7Zip archives take up more "size on disk" than .ZIP after DECOMPRESSION?

[kofman13]

I am doing a comparison between mac os native .zip archive utility and Keka .7ZIP. i am archiving a lot of project folders on my backup drive and i want to reduce even more size and i really like Keka interface and in most cases, 7zip with Keka gives me 10-20% smaller file sizes than native .zips.

one weird thing i noticed:
project folder is 981 mb, if i zip it with MacOS archiver, and decompress it again, the result is a 981mb (size on disk) folder again, just like the source.

BUT if i use .7zip compression with keka, and then decompress, the result is a folder with 1,020mb (size on disk) size.

Even the actual file size (not size on disk) is larger by 100-200kb. when decompressing from 7zip.

did something permanently change with my content i compressed? i am trying to archive things without any changes or issues. (the number of files is the same so i guess everything is fine, just weird that its larger AFTER decompression after compression than original source file.

 

[f54da]

hex diff the two files?

 

[bogdanw]

"Exclude Mac resource forks" https://github.com/aonez/Keka/issues/248

 

[Brian33]

Exclude Mac resource forks" https://github.com/aonez/Keka/issues/248

I don’t understand how this explains the observed behavior by the OP. If Kika/7zip were excluding the resource forks, the decompressed files should take less space than the decompressed standard zip files. It seems the OP is seeing the opposite.

This could explain why the compressed files are smaller for 7zip, though.

 

[chown33]

Can you make a simple test case? Say a single file in a folder, compressed both ways.

The forum software will reject uploads that exceed 16MB or so, I think.

It may also prevent a 7zip attachment (I've seen it reject certain types). If that happens, decompress the 7zip and recompress the resulting (larger) folder using Mac Compress's zip format, then attach that. Any additions made by going thru a 7zip compress/decompress cycle should still be present when that decompressed output is recompressed using ZIP.

 

[bogdanw]

I don’t understand how this explains the observed behavior by the OP.

I suggested a possible cause. The OP has not told us the settings used to create 7zip files.

There used to be an app that could solve this mystery fast: CompareFolders could point out the differences in folders, including hidden files.
Unfortunately, the developer removed the app from the App Store. The source code is public https://github.com/swisspol/CompareFolders

 

[NoBoMac]

Wondering if something special in the project folder, ala a sparse image type getting expanded? But not sparse bundle(s) per se, maybe...

Made a simple zip and 7z with MacOS Finder "Compress" and Keka respectively. Was able to extract via Finder double click on zip and used Keka and Unarchiver to open the 7z. All three returned same sized results.

Made a sparse image and repeated above: all three came back same sized. Now, my experiment might be faulty re sparse as I did not add anything to the image and might reflect different sizes if the image had something in it.

Seem to recall seeing discussions in the past re sparse types expanding to full size if not handled correctly hence my guess on something sparse-like and growing on restore.

And to add to what @f54da wrote: diff -r the source and extracted two extracted folders?

ADD: not links. Made some symbolic links and both zip and 7z returned same size copies upon extract.

 

[Mr.Fox]

I am doing a comparison between mac os native .zip archive utility and Keka .7ZIP. i am archiving a lot of project folders on my backup drive and i want to reduce even more size and i really like Keka interface and in most cases, 7zip with Keka gives me 10-20% smaller file sizes than native .zips.

one weird thing i noticed:
project folder is 981 mb, if i zip it with MacOS archiver, and decompress it again, the result is a 981mb (size on disk) folder again, just like the source.

BUT if i use .7zip compression with keka, and then decompress, the result is a folder with 1,020mb (size on disk) size.

Even the actual file size (not size on disk) is larger by 100-200kb. when decompressing from 7zip.

did something permanently change with my content i compressed? i am trying to archive things without any changes or issues. (the number of files is the same so i guess everything is fine, just weird that its larger AFTER decompression after compression than original source file.

In such cases, the archiver copies the data as is and then adds its own headers and other overhead, which increases the final size. There is no need to panic.

 

[NoBoMac]

A piece of info missing from OP: uncompressing to same filesystem and/or same format of filesystem? Eg. extracting to NTFS on one, other HFS or APFS?

Might be seeing affects from different block sizes for filesystems. Bigger allocation blocks on one vs other: might need two blocks on one but on smaller block system needs four blocks to hold same sized file. Byte count will be the same for file size but actually using up more disk to get the job done.

Along those same lines, lots of small vs mostly large files and block allocation can show similar oddities.

And: where are you getting the numbers from? If Finder Get Info, need to be looking at first number, not second, as the second number takes into account blocks assigned due to block sizes, system related overhead, etc.