revZIP library...

Paul Dupuis paul at researchware.com
Thu Oct 20 13:57:23 EDT 2022


Sean,

Thank you. I was searching the dictionary for revZip and did not see 
revZipDescribeItem, but from your post, I have found it and will try it. 
And of course, now I can see it when I get a list of APIs by just 
entering revZip in the Dictionary, so it was either a temporary 
Dictionary glitch or more likely my eyes playing tricks on me.

-- Paul

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 at 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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




More information about the use-livecode mailing list