<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Gerald, The simple fact is that ZIP files don't store "strings", they only store bytes. There were a few places in the Compression.pck.st that still made the old assumption that Strings and ByteArrays were "the same". I fixed those I found. I also added #addBytes:as:, that is what you usually want. Now, the following examples work: ZipArchive new zipFileComment: 'ZIP file test'; addString: 'ლორემ იფსუმ დოლორ' as: 'someText.bin'; writeToFileNamed: 'someText.zip'. ZipArchive new zipFileComment: 'ZIP file test'; addBytes: 'ლორემ იფსუმ დოლორ' asUtf8Bytes as: 'someTextBytes2.bin'; writeToFileNamed: 'someTextBytes2.zip'. Additionally, this example also works: ZipArchive new zipFileComment: 'ZIP file test'; addFile: 'Cuis-Smalltalk-Dev/CoreUpdates/5922-FixedClassMethodPushDown-TomásSpognardi-2023Jul09-20h38m-TS.001.cs.st' as: 'testOutx.bin'; writeToFileNamed: 'testbinx.zip'. So, I guess the problem you had with this file got also fixed along the way. All 3 zip files seem to unzip properly on my Mac. Please test again, and keep reporting further problems. Cheers, On 11/22/2023 8:13 AM, Gerald Klix via Cuis-dev wrote: <blockquote cite="mid:359d0387-cbe5-c452-6d34-5fcb0c26bb44@klix.ch" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Hi Juan, I got tried to work around this problem by reading the license files in binary mode and converting them to a string. However this leads to as CRC error: <tt> extracting: LICENSES.txt bad CRC 46294e2b (should be c42f8133)</tt> As promised I skimmed the ZIP file spec at <tt><a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT">https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT</a></tt> I only saw provisions for UTF-8 file names. Indeed we have problems storing such files; adding this one <tt><a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/CoreUpdates/5922-FixedClassMethodPushDown-Tom%C3%A1sSpognardi-2023Jul09-20h38m-TS.001.cs.st">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/CoreUpdates/5922-FixedClassMethodPushDown-Tom%C3%A1sSpognardi-2023Jul09-20h38m-TS.001.cs.st</a></tt> yields the following error when listing the contents with<tt> unzip -l</tt><tt> </tt><tt> </tt><tt> 1195 2023-07-19 20:39 Image/CoreUpdates/5922-FixedClassMethodPushDown-TomásSpognardi-2023Jul09-20h38m-TS.001.cs.s</tt><tt> </tt><tt>error: expected central file header signature not found (file #459).</tt><tt> </tt><tt> (please check that you have transferred or created the zipfile in the</tt> <div class="moz-cite-prefix">The biggest problem however is this one: Execute the following code snippet: <tt>'testIn.bin' asFileEntry forceWriteStreamDo: [ :ws | ws binary. ws nextPutAll: #[16rF1 16rF7] ]. ZipArchive new zipFileComment: 'ZIP file test'; addFile: 'testIn.bin' as: 'testOut.bin'; writeToFileNamed: 'testbin.zip' </tt>Then unzip the file with: bear@speedy ~/s/c/Environments> unzip testbin.zip Archive: testbin.zip ZIP file test inflating: testOut.bin This yields the following: <tt>bear@speedy ~/s/c/Environments> ls -l test*.bin -rw-r--r-- 1 bear bear 2 Nov 22 12:01 testIn.bin -rw-rw-rw- 1 bear bear 4 Nov 22 12:01 testOut.bin </tt>Invoking <tt>hexdump</tt> on both files shows a "slight" difference: <tt>bear@speedy ~/s/c/Environments> hexdump testIn.bin</tt><tt> </tt><tt>0000000 f7f1 </tt><tt> </tt><tt>0000002</tt><tt> </tt><tt>bear@speedy ~/s/c/Environments> hexdump testOut.bin</tt><tt> </tt><tt>0000000 b1c3 b7c3 </tt><tt> </tt><tt>0000004</tt> Obviously some UTF8 conversion happened. Needless to say that <tt>ZipArchive</tt> can't be used to compress binary files and thus I can't create a distribution of Haver with my current tool-set. Best Regards, Gerald On 11/22/23 10:21 AM, Gerald Klix via Cuis-dev wrote: </div> <blockquote type="cite" cite="mid:a929201e-c7f1-76b6-684b-cf4d30e116c8@klix.ch">Thank's Juan, this works now. Alas when I tried to create a new Haver release I ran into another problem. I also add strings to the ZIP-archive, for example a generated file that contains all the contents of all the license files found. The resulting string contains Unicode code-points, which makes the CRC computation fail. In essence when sending #updateCrc:from:to:in: the primitive fails – for obvious reasons – and the failure code kicks in. This in turn (indirectly) sends #bitXor: to a UnicodePoint instance, which results in a DNU exception. I will try to do some research on how UTF8 data is supposed to be stored in a ZIP file. Thank's again and Best Regards, Gerald On 11/21/23 9:12 PM, Juan Vuletich wrote: <blockquote type="cite">On 11/14/2023 10:20 AM, Gerald Klix via Cuis-dev wrote: <blockquote type="cite">Hi all, Hi Juan, The following snippet does not terminate (within reasonable time, 20h): (z1 := ZipArchive new) zipFileComment: 'ZIP test'. z1 addFile: SourceFiles first fileEntry as: 'f1'; writeToFileNamed: 'test.zip'; close. Adding small test files, created like this: echo test > test.txt , however does work: (z3 := ZipArchive new) zipFileComment: 'ZIP test'. z3 addFile: Smalltalk imageName as: 'f3'; writeToFileNamed: 'test.zip'; close. Best Regards, Gerald </blockquote> Hi Gerald, I just pushed a fix to GitHub. Thanks for reporting. Cheers, </blockquote> </blockquote> </blockquote> <pre class="moz-signature" cols="72">-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich</pre> </body> </html>