More feedback on $zip

I see the .crc property I suggested is in effect but not documented. But it's being returned as a base10 integer.

Suggestion#1: Unless for internal use, have $zip().crc return the crc as 8 hex digits like $crc does.

--

From brute force I see .cm .em .idx also return values. Through trial and error, it seems that .em returns 256 if it's been encrypted by aes, and otherwise is always 0. I have another program which can create encrypted zips using 3 different methods. $zip().em returns for the 3 methods:

256 = encrypted using aes256
256 = encrypted using aes128
0 = encrypted using pkzip 2.0 method
0 = not encrypted

I know zip format supports a wide range of encryption methods, so it's unreasonable to expect a different .em value for them all. $zip can extract the aes128 and aes256 methods but not the pkzip 2.0 method

Suggestion #2: Have $zip().em return some other value besides 0 and 256 for "sorry extraction switch 'e' will fail because encryption method not supported".

--

the .cm seems to be compression method, and a zip created by $zip always returns 8. For zips created by others I've got it to return '0' when the file is stored instead of compressed, or return '6' from obsolete methods used by pkzip v1.1. Not sure yet what kind of practical benefit that .cm will be for users.

At first, .idx was always returning 0, until I figured out that when a .zip has more than 1 file in it, that .idx is always 1 less than the N parm seen by the 'l' switch in $zip, so this probably won't have much help for the user who already know the N N parameter they passed to $zip.

--

Suggestion #3

$zip().mtime so users can see what's the timestamp of the file inside the zip.

Suggestion #4

Change current behavior which is to always give the extracted files the timestamp matching the time of extraction instead of the .mtime contained inside the zip. $zip correctly attaches the timestamp when compressing the file, it just doesn't use it when extracting.

Trivia note for interested users: When added to a .zip the timestamp is rounded down to an even number of seconds because that's all that's being stored inside the .zip where the date and time are each stored as 16-bit values, and there's only 5 bits for the 'seconds', so the values stored is $calc(seconds//2)

Suggestion #5

You didn't think it's useful to allow choice of compression level, but there's plenty of situations where it's useful. For example, when creating a .zip for purpose for longterm storage, or as an attachment where some email systems have a limit to the size of attachments. There can be a wide range of filesizes depending on the utility being used, and I'm not sure what levels are offered by the zip library being used here. My file manager offers choice of levels 1 through 9, and from comparing how it and $zip handle the current versions.txt...

280814 = filemanager's level 1
282496 = created by $zip(test.zip,co,versions.txt)
268436 = filemanager's level 2
...
230087 = filemanager's level 9

... which shows a 1-vs-9 difference of 18% for this particular file. These ranges of sizes look similar to the level of compression from $compress using 'l' with N=1 thru 9. Assuming versions.txt is in $mircdir :

//var %i 1 | while (%i isnum 1-9) { bread versions.txt 0 9999999 &v | echo -a $compress(&v,bl $+ %i) level %i : $bvar(&v,0) | inc %i }

I can't see a slightly slower compression time being a problem, unless someone is really doing some heavy-duty zipping, like trying to compress 100megabytes at the same time. The level-one could always be the default.

Suggestion #6

You mentioned not wanting to add complexity to $zip, so I assume that precludes being able to selectively add an additional file to an existing .zip or extracting only a single file from a multi-file zip. Those features are usually associated with complex switches for doing things like adding only when a file is newer, or adding only files within a range of timestamps. Perhaps a compromise would be the ability to create a list-file, which would be the scriptor's job to create it based on their own needs, such as limiting the filesize added to the zip, date range, etc. Then there could be a switch like '@' which would make the 'c' switch see parm3 as a text listfile containing relative/absolute file to be added instead of the parameter being a filename or foldername. That would avoid the need to create copies of files in the add-to-zip folder then delete the copies when done. That @list feature has been in zips for a long time, so I assume the zip library still supports it.

Suggestion #7

Have a way to add-or-extract the files without including the parent folder as if it's a subfolder. For example, create $mircdirZIPTEST and put versions.txt in it, then create a subfolder TEST below that and put aliases.ini in it. Then create zip:

echo -a $zip(test.zip,co,ZIPTEST)

The files are added to the zip as

ZIPTEST\versions.txt
ZIPTEST\test\aliases.ini

When you extract files, there's now no way to extract the files without including 'testfolder' as part of the extraction path, which means deleting the TESTFOLDER tree and then extracting like $zip(test.zip,e,ZIPTEST) this results in the files being extracted to:

$mircdir\ZIPTEST\ZIPTEST\versions.txt
$mircdir\ZIPTEST\ZIPTEST\test\aliases.ini

... instead of extracting versions.txt to the folder location from where it was added to the zip.