Zip file problem on Mac

matthias_livecode_150811 at matthias_livecode_150811 at
Wed May 4 18:35:07 EDT 2022

Neville, i can confirm that behavior even under BigSur.

I've created a small standalone with LC 10DP3 on BigSur and created  2  zip files  from the output folder using LC's zip library and using shell command zip.

Running the shell command 'zipinfo' to analyse both zip files showed, that the zip created with LC's zip library did not contain any executable permissions while the zip created with macOS zip shell command did contain the permissions.
So it seems the LC's zip library does not store the permissions in the zip.

According to your comment about The Unarchiver. Yes, i can also confirm that The Unarchiver and also Keka can extract the zip file created with LC and the standalone in the extracted folder is executable again.
As zipinfo did list all the files wihtout any executable permissions, i unzipped the zip with the shell command 'unzip' and that standalone was not executable again. All files showed exact those permissions that zipinfo showed before.

So i assume the following: Keka and The Unarchive seem to correct file permissions when they detect a folder structure that seems to be an app bundle. But that's just an assumption.
At least Keka seems to have such feature according to its change log Changes in version 1.0.11 <>

But anyway. The LC zip library ignores the permission when creating an archive.  If this worked before with older versions of LC  i cannot say, as i always used the zip shell command or tools like Keka.


> Am 04.05.2022 um 16:47 schrieb Neville Smythe via use-livecode <use-livecode at>:
> I distribute a Mac standalone via a zip file, created using revZipOpenArchive etc.
> This has worked fine until macOS Monterey or LiveCode 9.6.x 
> Either a bug has been introduced into the revZip tools in 9.6.x, or I have a corrupted version, or the Mac Archive Utility has changed so as to make the rev zip tool fail. Can anyone verify the following?
> On my Mac, the Archive Utility in Monterey, which automagically unzips files when a zip file is downloaded by Safari or double-clicked, now unsets the execute bit on the application (more precisely, on the executable file in the bundle). Which means the user gets a “This application could not be opened”, with no options to continue, when they try to launch the unzipped app. A terminal savvy user can use chmod x+ to make the app launchable, but I can hardly expect the ordinary user to have to do that. The execute bit is definitely set in the archive, because TheUnarchiver, a free third party decompression tool, unzips the file leaving the app launchable. This also suggests that the problem is not in my code.
> I can see why Granny Apple might have thought this was a good idea, executables in zip files are a the major sources of trojans, but if Apple has made this change it is a bit nasty because there is no obvious way to override the behaviour.
> If I use the Archive Utility to actually create the zip file from the standalone app bundle rather than using the rev tools, and then double-click it to decompress, the file unzips with the execute bit set. This shows the archive produced by revZip is not the same as that expected by the Archive Utility. It also suggests  a workaround would be to use Archive Utility from a shell command (it is not AppleScriptable – bad Apple!). From a cursory search on Stackoverflow,  the command line would be (this is not yet tested and the post is 5 years old)
> ditto -c -k --sequesterRsrc --keepParent
> to create the zip file for the Mac platform. The post says that is what the Archive Utility uses to compress files. Probably  the rev zip tools use zlib. Or maybe I should be creating a .dmg disk image instead of a zip file.
> Neville
> _______________________________________________
> use-livecode mailing list
> use-livecode at
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

More information about the use-livecode mailing list