LabVIEW
Include full path with ZLIB
Hi there,
I've made a zip file using the OpenG ZLIB tools of a main folder with some subfolders (years) containing identical filenames (monthly files).
Something like:
Data\2006\April.dat
Data\2006\Mei.dat
Data\2006\Juni.dat
Data\2007\April.dat
Data\2007\Mei.dat
Data\2007\Juni.dat
(File names are month's in Dutch 
)
The attached screenshot is the result of the zip file.
Only Filenames with no path, so I don't know from which year each file correspond and also I can't extract the files due to double filenames when extracting.
How do I include the full path in the ZIP file?
Any other suggestion as a work around are also welcome.
Thanks in advance!
Edit: Forgot this question
What's the difference between "File names" & "internal names (file name without path)" connectors?
I tried different connectios buth I never got the full path in the zip file 
Normally one would use the ZLIB Compress directory function for such a thing.
The internal path input is a (relative) path of the file inside the zip file, if you look at the ZLIB Compress Directory function you will notice that for every file, the base path is subtracted from the actual file path and that is used as the internal path.
For instance:
Dir to compress d:\data
File to compress d:\data\2009\augustus
Internal file name 2009\augustus
(more dutch names).
Veel succes,
Ton
LabVIEW user groep Hi Ton,
Alvast bedankt voor je reactie 
After posting I continue some trials and also used the "ZLIB Compress directory" vi but it too has an annoying behavior
Suppose I want to compress multiple folders into one ZIP file, something like:
C:\Program Files\App 1\File 1
C:\Program Files\App 1\File 2
C:\Program Files\App 1\Folder 1\File 11
D:\Data\File 11
D:\Data\File 12
D:\Data\Folder 11\File 111
I will end up with a zip file looking like
File 1
File 2
File 11
File 12
Folder 1\File 11
Folder 11\File 111
So, no way to know the original location of all files
The only way to get the (almost) full path in the ZIP file is to first copy all folders into a Temp folder and zip that Temp folder since zipping
G:\TempZip\Program Files\App 1\File 1
G:\TempZip\Program Files\App 1\File 2
G:\TempZip\Program Files\App 1\Folder 1\File 11
G:\TempZip\Data\File 11
G:\TempZip\Data\File 12
G:\TempZip\Data\Folder 11\File 111
result in a zip file looking like
Program Files\App 1\File 1
Program Files\App 1\File 2
Program Files\App 1\Folder 1\File 11
Data\File 11
Data\File 12
Data\Folder 11\File 111
Any idea why the ZLIB library subtract the base path?
Why not using the whole path?
If I'm not mistaken the original ZIP program had the ability to store the whole path, even with drive name, so one could restore all data in the original location. With the ZLIB library one can't do that.
Regards
Alain
Hi Alain,
Alain S wrote:Hi Ton,
Alvast bedankt voor je reactie
After posting I continue some trials and also used the "ZLIB Compress directory" vi but it too has an annoying behavior
..
Any idea why the ZLIB library subtract the base path?
Why not using the whole path?
If I'm not mistaken the original ZIP program had the ability to store the whole path, even with drive name, so one could restore all data in the original location. With the ZLIB library one can't do that.
Regards
Alain
I wouldn't know how a zip file could contain a drive path as well, it would be very weid to extact such a file on a different computer (or even OS).
Removing the base path is the thing that looks 'correct' to me, perhaps it is an idea to add an input to the VI that is similar to the internal name for normal files.
Ton
You are right Ton !
No drive path in the full path of good old ZIP program. I was mistaken 😞
But it had the choice between full or relative path so I felt free to modify the "ZLIB compress directory" so that the user has the choice between Absolute or Relative path.
It was easier to do than I thought 
Unless I overlooked something :smiley-sad:
Relative path:
Absolute path
Equal changes shoulde be made in the "ZLIB Compress files" vi, but that's for later 🙂
Well the ZLIB Compress Directory has to do something and most compress utilities will take the longest common path for all files as starting point. No need to include 10 levels deep of directory hierarchy if all files have that.
The right solution would be to make a variant of this called ZLIB Compress Directories, that takes an array of starting directories and then interactively works on each of them to do what ZLIB Compress Directory does. Or otherwise modify the ZLIB Compress Directory to use the "append to archive" method when opening the archive the second and all successive times, each time with another base path. The proposed solution to include the entire path sounds like a big hack to me, and I will not add that to the library.
Rolf Kalbermatter
rolfk wrote:... ... that takes an array of starting directories and then interactively works on each of them to do what ZLIB Compress Directory does. Or otherwise modify the ZLIB Compress Directory to use the "append to archive" method when opening the archive the second and all successive times, each time with another base path.
That is exactly what my calling vi does, run through an array of directories on different locations/drives 
How come you know what I'm doing???
Don't need to modify the ZLIB Compress Directory vi to use the "append to archive" stuff. In the loop of the calling vi use the loop counter to connect "create new" when it's equal to 0 or "append to archive" in other cases, to the "append (create new)" connector.
rolfk wrote:
The proposed solution to include the entire path sounds like a big hack to me, and I will not add that to the library.
I don't see what's the problem here, the original ZIP program has this possibilty so, what's the problem????
The idea is that the user knows the original location of all files. When using those vi's to make a backup/archive-like application one would be interested to know the whole path (except drive letter) so that when the files needs to be restored, the complete, correct folder can be created.
@Alain S wrote:
Don't need to modify the ZLIB Compress Directory vi to use the "append to archive" stuff. In the loop of the calling vi use the loop counter to connect "create new" when it's equal to 0 or "append to archive" in other cases, to the "append (create new)" connector.
My bad, it's been some time that I worked on that library, and I wasn't exactly sure if this parameter was exposed by that VI.
I don't see what's the problem here, the original ZIP program has this possibilty so, what's the problem??
Well for one thing I did not want to write a pkzip replacement 
. Instead I wanted to write a library that allows to distribute LabVIEW code. This library is at the core of the OpenG package format, which is used by the OpenG Commander and its professional successor VIPM.
And the library is as it is already quite big, has already many more or less complex options, but as you have found out is still very easy to adapt to whatever you want to do if you dig a little into its workings.
Rolf Kalbermatter
Hi Rolf,
what about this idea:
.
This gives a user the oppertunity to place the directory inside a folder in the archive.
Ton
It would be a possibility except for two reasons:
1) The ZLIB Compress Directory connector pane is already quite full.
2) and more important because of this remark in the diagram: "ZIP files should also contain a file entry for each subdirectory they contain, but not for the '.' dir"! So there would be additional work to be done here.
Rolf Kalbermatter
