revZipExtractItemToFile: merge or replace?

[trevix]

Does anyone know if doing a revZipExtractItemToFile, of a Zip file containing a folder named "X, to a directory where there is already a folder named "X, there is a merge, a replace or else?
In the dictionary I could not find a reference on this.

By the way, I have a few questions on the Zip stuff, on LC 10:
- is there a RevZip external to be enabled somewhere for mobiles?
- what is the "Revolution ZIP" extension?
Thanks

[richmond62]

Why not try that out to find the answer?

[trevix]

I did, but could not come to a final verdict.
I am working for mobile devices, where things are more complex.
Beside, if the existing folder contains an open stack, I have to close it first (destroy) so that it get replaced by the one from the zip file. But somehow it seems that the stack is still in memory sometime. Could be "timing"?

[Klaus]

Hi Trevix,

here a handler which I "borrowed" from the LC IDE, this will close and remove a stack from memory COMPLETELY!:

Code: Select all

command closeAndRoveFromMemory tStack
   local tSubstacks
   put the subStacks of stack tStack into tSubstacks  
   lock messages
   repeat for each line tSubStack in tSubstacks
      close stack tSubStack
   end repeat
   delete stack tStack
   unlock messages
end closeAndRoveFromMemory

Hope that helps!

Best

Klaus

[richmond62]

closeAndRoveFromMemory

strikes me as very odd indeed: might closeAndRemoveFromMemory be better?

[Klaus]

Oops, never had a deeper look!?

I copied this from a LC lesson PDF, and that (copying text from PDF files) tends to "lose" some chars from time to time.
And of course it correctly reads "closeAndRemoveFromMemory" in the PDF.

[trevix]

I can confirm that revZipExtractItemToFile does a merge: new files are added, same name files are replaced, but old files not present in the zip are not deleted.
By the way: why unzipping on LC is so much slower than a OS unzip (not even comparable)?
Is there anything that can be done on this regard?
Trevix

[FourthWorld]

How large is the archive?

[trevix]

36MB uncompressed.
On OS, unzipping is about 3 secs on Sonoma
LC UnZip, using the routine with status bar, 20 or more seconds.

Code: Select all

 -- Open the archive for reading.
     revZipOpenArchive pArchive, "read"
     -- As the work happens in the revZipExtractItemToFile in this case, we register the callback here.
     revZipSetProgressCallback "zipProgressCallback"
     
     repeat for each line tItem in sZipListOfFiles
          if char -1 of tItem is "/" then
               -- we ignore extraction of folders, as libzip doesnt handle folders
          else if item 6 of revZipDescribeItem(pArchive,tItem) is "deflate" then
               -- first make sure that the folder exists
               set the itemDel to "/"
               ensureFolder tLocation & "/" & item 1 to -2 of tItem
               set the itemDel to ","
               revZipExtractItemToFile pArchive, tItem, tLocation & "/" & tItem
          else
               put true into tCouldNot
          end if
     end repeat
     revZipCloseArchive pArchive

[FourthWorld]

36 MBs fits into RAM nicely. I wonder if it's faster to read the files into an array and then encode and compress the array to store on disk.

[LCMark]

@trevix: What is `zipProgressCallback` doing? Try not setting a progress callback and seeing what the speed is.

[trevix]

Your were right, as usual.
Without the callback it is almost instantaneous.