V18 R2 and Zip Create Archive not working?

Hi,
I use the zip generation and I get a strange result.

But the zip file has been made, and $status is successful (!):

$status:=ZIP Create archive($ob_source;$ob_target)

image

And the zip is dezipable !

Strange. Perhaps it is a bug when my target is a package on mac Os X ?
As here, I am zipping package CONCERTo.app which is a “Final Application” engined.

Hello Olivier,
Could you give us the code above ? When you create your $ob_target object ?

Bonne journée !

A good habit, as a developer, is to always open the details panel of the error dialog. This allows you to see the call string and maybe the original error is not the one displayed…

2 Likes

so far, so good, so true. Why it is collapse by default? Can we get is opened by default?

1 Like

Even if this dialog should not be displayed to the end user (your client) it happens…
I think this message is already confusing enough for the end user without adding the complexity of the call chain and options (among other things, did you know that you can copy the errors chain to paste it into a message, rather than pasting an image. It’s more informative than a picture).

I think this subject should be discuss in a new thread as feature request

1 Like

The dialog is not good for end user nor for the developpers so it’s good for who ? :roll_eyes:

Hi Bérengère,
in fact, the construction of this object is very generic, in order to create it for Mac and Windows, and for mono engine, and server and client engine.
The goal is to finish a build by moving some extra folders and files (“www”, prefs files…) in targets, then zip them.

  // Construct varas for the three engines, mono, server and client
C_TEXT($finalApp;$clientServer;$base_name;$builds;$app;$contents)
$base_name:="CONCERTo v5"
$builds:="CONCERTo_Builds/"
$app:=Choose(Is macOS;".app";"")  // Mac Win difference
$contents:=Choose(Is macOS;"Contents/";"")  // Mac Win difference
$finalApp:="Final Application/"
$clientServer:="Client Server executable/"

C_TEXT($path_www_target;$path_www_target1;$path_www_target2)
$path_www_target:=Folder(fk database folder).platformPath
$path_www_target:=v_ParentPath ($path_www_target)

  // For engine mono
$ob_folder:=Folder($path_www_target;fk platform path).folder($builds+$finalApp)
$ob_source:=$ob_folder.folder($base_name+$app)
$ob_target:=$ob_folder.file($base_name+".zip")
$ob_target.delete()
$status:=ZIP Create archive($ob_source;$ob_target)

  // Then next server, client...

And a fresh opened capture: I think I guessed the bug…

All in mac.
Related to package. If I declare target (“CONCERTo v5.app”) as a file, the zip don’t want to start, if I declare it as a folder, the zip don’t want to finish :slight_smile:

Hello Olivier,
maybe I will answer a wrong thing but you use character “/” at the end of your folders name :

C_TEXT($finalApp;$clientServer;$base_name;$builds;$app;$contents)
$base_name:="CONCERTo v5"
$builds:="CONCERTo_Builds/"
$app:=Choose(Is macOS;".app";"")  // Mac Win difference
$contents:=Choose(Is macOS;"Contents/";"")  // Mac Win difference
$finalApp:="Final Application/"
$clientServer:="Client Server executable/"

I suggest to use the constant “Folder separator” instead :

C_TEXT($finalApp;$clientServer;$base_name;$builds;$app;$contents)
$base_name:="CONCERTo v5"
$builds:="CONCERTo_Builds"+Folder separator
$app:=Choose(Is macOS;".app";"")  // Mac Win difference
$contents:=Choose(Is macOS;"Contents"+folder separator;"")  // Mac Win difference
$finalApp:="Final Application"+Folder separator
$clientServer:="Client Server executable"+Folder separator

The error dialog shows that your folder “CONCERTO v5.app” is not found when it tries to zip, whereas your zip archive is still created (did you check the content of this archive ?)

And yes, a package is a folder that’s why using a file type object causes an error when starting creating the zip file (there’s an folder object type attribute “.isPackage” to check if a folder is a package or not).

Hope this can be helpful:)

In fact this line is not used here… But the / is to be used after with a folder or file command, in POSIX syntax, that is why…

Thanks, did know that.

No: the error comes at the end of the zip génération (20 seconds…), and the zip is created, and yes, I checked the content by unzip it, no error, zip is ok.
That’s why I’m thinking of a 4D bug when the source is a package ?

There is a little difference in size from the one made by 4D, and the one made by Finder “CONCERTo v5 2.zip”.

And if I unzip the 4D one, I get a file with less bytes, even with no error when unzipping it…

image

Yes sorry, I was thinking about this line :

$ob_folder:=Folder($path_www_target;fk platform path).folder($builds+$finalApp)

And I didn’t noticed that .folder() member function was using POSIX syntax… my bad !

And what if you use Zip Create archive with a zip structure object as first parameter ?
(I suppose the issue will be the same…)

I’ve tested with v18 R2 on a Mac to zip a package “.4dbase”, I didn’t have any error message. But the path of my package was easier than yours…

:sweat_smile: :sweat_smile:

And also your package is a “.4dbase”, mine is a “.app”…

I’ll check with a zip structure object, let see…

I think it would be interesting to get an opinion from 4D engineering, whether or not the built-in zip commands are designed for archiving apps. I know that my plugin is not good for that purpose, so I recommend ditto to my customers. With my plugin, a zip file is created and can be expanded, but the app will be sent directly to trash by the system.

I sincerely hope the same doesn’t happens with the built-in commands.

1 Like

:open_mouth: Without any action ? Just unzipping it goes into trash ? How it is possible ?

Sorry, I should have been more specific.

A zip file is created, unzipping on a different computer would create an app with the correct icon and everything, but launching it would alert GateKeeper. I assume the code signature doesn’t match.