Unfortunately, revvZipDescribeItem only returns a meaningful value for the compressed_size of an item if the archive has already been compressed. A new archive is only compressed on revZipCloseArchive (typically at the end, once all items/files have been added using revZipAddItemWithFile archivePath, itemName, filePath)

revZipDescribeItem(archivePath, itemName) -- This function returns a comma delimited list of details in the form: index, crc, size, mtime, compressed_size, compression_method.

In a test, I get the following. Item 5 of the function revZipDescribeItem is -1 for new item added to a new archive. Item 3 is the size, which is the uncompressed size in bytes, which I could also get through the 'detailed files'.

20220520_Cole Video Crossties Grooming.mp4 : 0 :0,0,1881779936,1653078796,-1,none : -1
Cole massage 2021 12Dec06.mp4 : -1 :0,0,284857583,1638822998,-1,none : -2
Equine Discomfort Ethogram Illustrated.pdf : -2 :0,0,10318431,1652185660,-1,none : -3 Equine Discomfort Ethogram paper.pdf : -3 :278290080,0,12407958,1652184150,-1,none : -4 The Horse Grimace Pain Scale with Images and Explanations.png : -4 :0,0,1420824,1653940632,-1,none : -5

I think I just need to go back to adding up the uncompressed sizes, either via revZipDescribeItem's item 3 or the detailed files, and raise a warning if I get to 2GB


On 10/20/2022 12:04 PM, Pi Digital via use-livecode wrote:
Do you have no success with the revZipDescribeItem() function. This should give 
the compressed size directly after compression.

Sean


On 20 Oct 2022, at 16:31, Paul Dupuis via use-livecode 
<use-livecode@lists.runrev.com> wrote:

In addition to the revZIP library, whether building for 32 bit Windows 
standalone or 64-bit Standalones, still (as of LC 9.6.8) has a 2GB limit on 
archives it can open and a 2GB limit on what it can save, there appears to be 
NO mechanism to get the compressed size of an item (file) in the archive. 
Neither the revZipAddItemWithFile nor the revZipAddItemWithData, nor any other 
API in the dictionary lets you get the compressed size of something after 
compressing it.

This is especially annoying with the 2GB limit on saving an archive and that 
error only occurs when you call revZipCloseArchive at the end. That means if a 
user of your application tries to archive a list of file that are 50GB or some 
even larger number the code happily compresses everyone, going well over 2GB 
until it tries to close and save the archive at the end and ONLY after all that 
wasted time do you get an error.

I can obviously get the uncompressed size of each file (using detailed files) 
and keep a running total and IF that total hist 2GB then stop a process that 
MIGHT fail in the end. However, perhaps their uncompressed files are 2.5GB but 
when compressed would be 1.8gb and work.

Folks have already suggested abandoning the revZIP library and using shell to 
invoke native command line tools (although no call backs for a progress bar is 
possible with CLI tools, which, is a BIG disadvantage to that approach for our 
users). However, I really wish the revZIP library just worked right.

On a long shot, does anyone know of a clever trick using the revZIP library, to 
get the compressed size of an item after you compress it?

I suppose I could open the archive, compress 1 item, close the archive, check 
the size of the archive via detailed files, and then open the archive  add the 
nest compressed file, close, measure the size and so on, but I feel the 
overhead would slow down and already slow process even further.

My best option may be to just add up the uncompressed sizes of the files 
involved.

Any clever ideas welcome!


_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to