Open a bug report and I will +1 it. Bob S
> On May 4, 2022, at 15:35 , matthias rebbe via use-livecode > <use-livecode@lists.runrev.com> wrote: > > 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. > But... > 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 <https://changelog.keka.io/#v1.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. > > > Matthias > > >> Am 04.05.2022 um 16:47 schrieb Neville Smythe via use-livecode >> <use-livecode@lists.runrev.com>: >> >> 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 Product.app Product.app.zip >> >> 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@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
