revZIP library...

[Sean Cole]

It must be creating a temp file or placing it in memory somewhere. Is there
perhaps a way to hack that and find out how many bytes are being stored?
Just thinking out loud before catching some zzz's. I hope you find some
solution.
Sean


On Fri, 21 Oct 2022 at 00:38, Paul Dupuis via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 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 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
>
>
> _______________________________________________
> 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
>