Do you ship support files in a Zip Archive?

So, for many years I have shipped support files in the form of a zip file in the resources folder, unzipping at first run.

To make that zip file, I created a folder full of files and folders of files, then used ‘Compress’ on my Mac to create Archive.zip, which I renamed.

Today, having run into a filesize limit with my resellers, I have spent some time working through the contents to see if I could trim any superfluous files.

BUT

I have discovered that using Windows to zip the exact same folder, the zip file produced is HALF the size that the Mac produces on the same data.

It’s made an enormous difference to the size of the installers, and the resulting zip file works perfectly on a clean mac.. nothing important is missing.

What on earth is MacOs wrapping up in this archive?

( _MacOS folders etc etc, but I expected them to be tiny attribute files)

There are multiple possible compression levels on zip files, where speed and size are traded-off. The likely scenario is that the default compression level on Windows is higher than it is on Mac (presumably so that the compression process is speedy). There might be a way to set your desired compression level on Mac, perhaps in Finder? - I am not very familiar with the Mac. It is not possible to adjust the default compression level on Windows, which is why I was using 7zip while I was working on a Windows computer.

1 Like

Do you mean you right click the folder and choose ‘Compress’ from within the finder by hand?

If so, I believe this uses the ‘tar’ command and you can play around with scripting this using various compression algorithms. Modern tar on macOS supports several such as bzip, lzop, lzma, zstd, lz4, lrzip, xz and others.

Not all will work on older macOS or Windows systems, so you should test carefully.

run man tar in the terminal for more info

Yes.

However, this only gets done once in a blue moon. I’m happy to use my Windows VM to do the job.

This post is a PSA for anyone else who has been doing it ‘my way’.

I literally shaved 90Mb from the installer by this switch!

There are Mac apps that give you much more control over compression options as well.

(download from the website is free)

4 Likes

I’m a big fan of Keka, which is also available (I think for free?) via the Mac App Store.

I happily gave them a “tip” via in-app purchase because it’s a great little app.

Anthony

If you still want to do it on the Windows VM, take a look at 7Zip. It is a most useful freeware. You can define the compression level, the type of archive (it supports pretty much everything), and more. Together with the other suggestions, you should be able to find a solution that suits you well, and reduce even further the size of your installers.

1 Like

As it happens, (for my stuff) zip at level -9 doesnt save much over the default in Windows.

All of this talk of compression levels misses the actual cause of the BIG issue.

When I compress on a Mac, it includes a _MacOSX folder, and in that, a copy of ALL the actual files, prefixed by _

If I have a file called Testing.PNG with a file size of 400K, there is another (which is no use to me) , called _Testing.PNG , also 400K in size. I had imagined that these prefixed files were tiny info files - resource forks that held opening state, owner app and suchlike. But they are full size copies.

So in fact, rather than compressing a folder to a smaller size, on Mac what you get is a zip file that can be bigger than the original.

Using Windows to zip the same (Shared) folder omits all this duplication.

I’m guessing this is Mac’s way of giving you time machine/rollback ability?

If so, then despite usually having smaller SSDs than most Windows machines, they are eating up the used space with this duplicated data.

Thats pretty annoying, actually.

As you note, the hidden _MacOSX folder holds resource forks. However, those should generally be empty, as modern Mac apps generally do not store data in resource forks.

Are you doing something weird with how you generate these image files???

BetterZip ($24.95) gives you the ability to create zip (or other archive format) files without all these unnecessary macOS files. You can create presets to exclude files when saving to an archive. It has already predefined presets and “Clean and Zip” is one of them. This creates zip-files without the macOS rubbish.

Here’s a test:

  • make a folder on macOS, add a PNG file
  • right-click in finder and choose “Compress”
  • copy zip file to Windows 11
  • Extract All

File size of dice.png is 58KB
File size of _MACOSX/_.dice.png is 1KB (actually 333 bytes)

So I’m not reproducing your claim that the hidden files are the same size as the originals.

3 Likes

And to give you a bit of a hard time, all this talk of compression levels ignores the really BIG issue: you are hand-building your release apps! :grinning_face:

You should script your release build using command-line tools.

If you are building your app on macOS, the command is something like this:

ditto -ck --keepParent --norsrc --noextattr --noacl /path/to/my/folder/*.png  /path/to/my/pictures.zip

-c means “create”
-k means “use PKZip format”
–norsrc, --noextattr, and --noacl turn off the macOS specific filesystem metadata
–keepParent : keeps the parent folder in the Zip file - you may or may not want this depending on how you extract the files later.

3 Likes

ignores the really BIG issue: you are hand-building

No. Really. The zip file contents might change once per year. Made once, added in the ide.

No issues.

Are you doing something weird with how you generate these image files???

Nope.

Select a bunch of stuff, right click, compress.

Do the same on the same folder (shared) using my windows VM, the zip is half the size

Unzip the big one in windows and I see all the _ files.

Delete them and the size of the unpacked folder halves.

I have read that these files don’t exist if the file system is apfs or journalled.

Well in my opinion all you need is one of the tools mentioned. Whether commercial or free like Keka, you just need a Mac app that lets you create a zip without the macOS hidden junk. No need for a VM or Winders :slight_smile:

In general, I’m not seeing evidence (other than your claim) that zipping a file on a Mac will double the zip size.

Zipping on mac will increase the Zip file a little, due to the (mostly empty) resource folks stored in the _MACOSX folder, but it won’t double.

If you are sure the zip file is doubling in size, there must be something else going on.

Ideas:

  • something weird is happening when you add the zip file to the IDE? Can you say more about how you do that?
  • you have other hidden folders that perhaps contain copies of the assets? For example, some version control systems keep original copies of assets in hidden folders.
  • you are editing the PNGs with an app which accidentally stores data in the RSRC fork?
  • gremlins?

This is in one aspect amusing, and another , perplexing.

I’m not seeing evidence (other than your claim)

I now feel as if I am on trial. :slight_smile:

I have been investigating further, but before I get to today’s findings:

  • something weird is happening when you add the zip file to the IDE? Can you say more about how you do that?

The file was big before it hits the IDE. I just drag it in

  • you have other hidden folders that perhaps contain copies of the assets? For example, some version control systems keep original copies of assets in hidden folders.

I have no such version control on that folder

  • you are editing the PNGs with an app which accidentally stores data in the RSRC fork?

Could be… I’ll investigate that more at some point.

  • gremlins?

This one, I can give some credence to! :slight_smile:

In an attempt to prove ‘my innocence to the court’, I did this:

1/ (My old way) - opened the folder in Finder, selected the contents, right click, compress.

  • result - extra big archive.zip produced

2/ Deleted the archive.zip. Duplicated the folder. Moved it to a fresh location . Deleted maybe 60% of the contents. Selected contents, right click, Compress, and … normal kind of archive produced.

The original folder and contents have been built up over time, and the current folder has a creation date of 2017.

So, at this point,

maybe one of the sub files or folders has been the cause of the oddity.

Maybe the location of the folder is the cause.

Don’t worry about it - I have a working solution which I am happy with.

As a reminder, on macOS in the Finder, type Command+Shift+. (command-shift-period) to toggle on / off the viewing of invisible files and folders.

Oddly, there is no menu item for this command, it’s just “secret”.

Correct, but these ._Filename items won’t appear in the Finder, even using this trick (they’re not “hidden files”, but rather “metadata”).