Unzip does not preserve permissions

[radianbaskoro]

I created a zip archive with Finder (right click Compress), and extracting it by double clicking on the finder puts the same permission back. Using the unzip method somehow resets the permissions.

I looked at the archive produced using zipinfo, it has the permissions stored. Changing umask also didn't have any effect.

Trying to use this with SET UPDATE FOLDER but didn't have the right permissions for the app and errors on restart.

[miyako]

did you try the option ZIP_With_attributes ?

[radianbaskoro]

I created an empty file with modified permissions

> touch test.file
> chmod 777 test.file

And used the zip method as you suggested:

$src:=Get 4D folder(Database folder)+Folder separator+"test.file"
$dst:=Get 4D folder(Database folder)+Folder separator+"4dZipPlugin.zip"

$success:=Zip ($src;$dst;"";ZIP_Compression_level_1;ZIP_With_attributes)

And here's what zipinfo gave me

Archive:  4dZipPlugin.zip   118 bytes   1 file
-rw----     0.0 fat        0 b- defS 22-Nov-16 08:08 test.file
1 file, 0 bytes uncompressed, 2 bytes compressed:  0.0%

Using the built in archive utility gives me the right permissions

Archive:  test.file.zip   144 bytes   1 file
-rwxrwxrwx  2.1 unx        0 bx stor 22-Nov-16 07:51 test.file
1 file, 0 bytes uncompressed, 0 bytes compressed:  0.0%

[miyako]

thank you for the detailed information.

while I confirm that zipinfo systematically returns -rw---- (644) on archives created by the plugin, I also see that such an archive does assign the right permissions, whether you use archive utility, or the plugin itself to unzip it.

$s:=System folder(Desktop)+"test"
$d:=System folder(Desktop)+"test.zip"

$success:=Zip ($s;$d;"";ZIP_Compression_level_1;ZIP_With_attributes)

$s:=$d
$d:=System folder(Desktop)+"test.result"
$success:=Unzip ($s;$d;"";ZIP_With_attributes)

[miyako]

I am guessing the "version made by" bytes are misguiding zipinfo to think that the file was created on windows https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

[miyako]

no, it was assuming UNIX by default, and setting 3 for UNIX didn't make a difference. but again, I would like to stress, the permissions are preserved, just not reported by zipinfo.

[radianbaskoro]

Hey @miyako, sorry for the late follow up. I just got back to work.

I tried this again, and the zip using ZIP_With_attributes does store the proper permissions also evident with zipinfo, but the unzip plugin method somehow loses it (reverts back to 644).

I created a test file with permission 666, and zipped it with the plugin, then unzipped it two ways. The first one with the plugin in the UnzipPlugin directory has the file permission reset to 644. The second one with launching unzip command has the file permission still at 666.

Here's a snippet to reproduce the scenario.

C_TEXT($src;$dst)
C_LONGINT($success)

  // Create file
$dst:=Get 4D folder(Database folder)+"test.file"
TEXT TO DOCUMENT($dst;"hello world")

$dst:=Get 4D folder(Database folder UNIX syntax)+"test.file"
LAUNCH EXTERNAL PROCESS("chmod 666 "+$dst)

  // Create zip
$src:=Get 4D folder(Database folder)+"test.file"
$dst:=Get 4D folder(Database folder)+"test.zip"

$success:=Zip ($src;$dst;"";ZIP_Compression_level_1;ZIP_With_attributes)

  // Unzip with plugin
$src:=$dst
$dst:=Get 4D folder(Database folder)+"UnzipPlugin"

Unzip ($src;$dst)

  // Unzip with command line
$src:=Get 4D folder(Database folder UNIX syntax)+"test.zip"
$dst:=Get 4D folder(Database folder UNIX syntax)+"UnzipCommand"
LAUNCH EXTERNAL PROCESS("unzip "+$src+" -d "+$dst)

Thanks a lot for your support, and メリークリスマス

[miyako]

are you passing ZIP_With_attributes to Unzip?

[radianbaskoro]

That I did not do. It wasn't in the readme, so I assumed it was the only behaviour. Am I missing the documentation somewhere?

[miyako]

it was used in the sample 4DB.

true, the Japanese documentation is more articulate https://github.com/miyako/4d-plugin-zip/blob/master/README-JA.md

but I likewise "assumed" that it was obvious that the same option applied to both commands.

[miyako]

so did it work?

can we close the issue?

[radianbaskoro]

Works as you described it. Thanks.