Unzip to memory

[JackDunaway]

This idea will probably have a narrow audience... those of us who use the "zip" functions in LabVIEW. There is currently an unzip function that takes a zip file on disk, then writes the unzipped files back to disk. To manipulate zipped files, you must then access the disk and load into memory. In other words, 3 disk operations... read zip, write file, read file.

There needs to be a function that unzips the files into memory, with the output of this function as an array of flattened strings, byte arrays, or data pointers.

Message Edited by Support on 06-09-2009 08:35 AM

[Jim_Kring]

FYI, the OpenG Zip Tools library supports zipping and unzipping files and strings to memory.

[JackDunaway]

I took a look through the library, and cannot find a VI that returns the contents of the files in a zip file to a memory buffer. I found a dll call wrapped in "ZLIB Read Compressed File" that ultimately just writes the unzipped buffer contents to a new file specified, so I guess I could just use that portion of code for the in-memory ops.

I'm leaning toward the 7zip SDK dll calls right now.

[JackDunaway]

Jim,

Realized today that you were probably talking about "Inflate" and "Deflate" VI's (am I right?). These look even more viable than the 7zip library. The compressed (deflated) file is read as a binary file with vanilla LV function, then the contents are passed into the "Inflate" function. Voila... you have the uncompressed contents in memory without 3 disk ops! To anyone reading this, the OpenG compression routines are winners.

Thanks,

Jack

[rolfk]

Actually the OpenG ZIP library is even more versatile than that :-). It supports memory streams (string buffer) both as source and destination for compression and decompression as well as file based and the according mixes thereof.

The Inflate and Deflate functions are just a very simple functionality to inflate a single stream into a compressed stream and deflate a compressed stream into a decompressed stream. They do not support any archive structure however (which is the basic feature of ZIP files).

But with the stream based ZIP functions you can actually have both file and memory based archives and extract from them into file or memory based data files or vice versa. I think VIPM makes use of that to speed up downloading of VI packages as this saves slow disk IO for temporary storage of the archive prior to installing them.

[JackDunaway]

Just a quick update after making this request over 1.5 years ago - OpenG compression works great on both desktop and RT targets, and like Rolf says (yes, he would know 😉 ), it's versatile enough to handle my compression needs.

And if that's not enough... the .NET compression (and encryption) libraries have great desktop support for several protocols and data sources (stream, string, file).

Spoiler

Sidestepping... My philosophy on the vi.lib has changed over the past year and a half - specific domains such as this are better left with third party providers (in this case, the community and OpenG) rather than requiring NI to adopt the library and the associated burden of support, maintenance, documentation, feature requests, etc...

It makes sense (in my mind) for NI's relatively limited resources to stay devoted largely to streamlining/adding features to LabVIEW core and improving IDE workflow and API hooks, leaving the virtually unlimited community of LabVIEW users to provide the toolkits.

I hope this Idea is labelled "Declined" for reason of the existence of a proven, suitable alternative to additional code in the vi.lib.

[Darren]

Any idea that has received less than 8 kudos within 8 years after posting will be automatically declined.