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