A full ZIP API

[EricC.]

Having a complete API for zip file

Currently it has :
- New zip file
- Add a file to zip file
- Close zip file and add a comment
- unzip the zip file to a folder

This API is not quite complete.

Example of use of ZIP files: In a data streaming application, you want to make an archive of recordings files. The data files average 500 MB Once compressed, they do more substantive than 50MB. You create an interface to assist the user in steps of compression. Once compressed, you want to propose an interface for retrieving compressed recordings.

The ideal is to list the files and clarify some information, such as track number, recording time and a few other indicators related to data.

But to do that, we 'could' use two ways:
- The properties of the zip file.
- An additional file that would read that to see them.

Several problems arise:
- It is not possible to read the commentary added with the close function.
- It is not possible to edit the commentary added with the close function.
- It is not possible to decompress a single file.
In the example, if we unpack all files to read properties, it'll take time and a lot of CPU resources.

It would require full management functions:
- New file
- Close file
- Add a comment
- Read the comment
- Erase the comment
- Add a file
- Delete a file
- List all file (with or without a mask)
- Uncompress a zipped file to disk
- Uncompress a zipped file to memory

- compress and uncompress a string in memory (usefull to optimise the network data flow)

In the ideal case, a zip file should be considered a folder. So we have all classical file functionality to manage it.

[Jim_Kring]

Hi!  Did you know that OpenG has a great zip library that is very full-featured?  See here for more details:

http://wiki.openg.org/Oglib_lvzip

Message Edited by Jim Kring on 02-08-2010 09:28 AM

[Jervin Justin]

Hi Eric,

We just launched a new branch of the NI Idea Exchange to foster ideas for LabVIEW Add-ons. The intent was to create a place for LabVIEW Add-on developers (both NI R&D and developers in the community) to find ideas that matter to the community.

This is part of our ongoing effort to enable LabVIEW developers to productize LabVIEW code. Some of the other things we’ve done this year were adding Licensing & Activation for 3^rd Parties, launching the Compatible with LabVIEW Program and the LabVIEW Tools Network.

We’ve identified your particular idea as one that could potentially be made into an Add-on and would like to move it to this new Idea Exchange so that Add-on developers can easily find it. Would this be okay with you?

Thanks!

[Brad]

I'd also like to add that dealing with ZIP files that are password protected doesn't work. When I use the current LV Unzip.vi, it correctly saves all the right files, and returns no error, but the files all have a size of 0. It would be nice to:

1. Provide a password input to this VI.

2. Return an error if the ZIP is password protected and the incorrect password is supplied, and don't save emtpy files.

[crossrulz]

I have an application right now that could really benefit from this.  The part that we really need is the ability to unzip individual files instead of having to unzip everything at once.

[Hooovahh]

Yes, so glad I'm not the only one.  I'd really like it if NI came up to the coding functionality provided by OpenG back 15 years ago!  Mainly I'd be looking for better support for extracting single files, adding a file, deleting a file, and password support.  All things OpenG does pretty well, among other low level functions.

[wiebe@CARYA]

I'd also like to have

- inflate

- deflate

compression available. Zip uses that, so the functionality is there, but not exposed.

Zlib is good, but it's an all or nothing deal. Zlib, requires the error handling which requires the string library, etc..

The dll export functions (at least the unzip) used by LabVIEW use memory to decompress. It's the PW protected VI that stores it to disk. Decompressing to memory should be (is) a peace of cake.

It's just frustrating that we have to install additional code because the available functionality isn't exposed.

It's also convenient to know the functions are there on any target, as the functions are available in the RTE. No need to worry about 32\64 bits, OS, cross compiling, etc... At least not for us...