bug ZLIB Specific Path to Common Path (not working on Mac OSX)

[Michael Aivaliotis]

The following VI is part of the OpenG LabVIEW Zip Library:

 

ZLIB Specific Path to Common Path__ogtk.vi

 

 

If you notice, the case structure supports Mac OS, but not Carbon. The App.TargetOS output is Carbon. I'm running this on Mac OSX 10. This has a ripple effect in that I cannot use some of the Zip tools to compress files on Mac.

 

Not sure who will be fixing this, since JGCode is on hiatus. But I'm reporting it here for the Googlers of the future.

[Rolf Kalbermatter]

The following VI is part of the OpenG LabVIEW Zip Library:

 

ZLIB Specific Path to Common Path__ogtk.vi

 

2013-03-13_1700.png

 

If you notice, the case structure supports Mac OS, but not Carbon. The App.TargetOS output is Carbon. I'm running this on Mac OSX 10. This has a ripple effect in that I cannot use some of the Zip tools to compress files on Mac.

 

Not sure who will be fixing this, since JGCode is on hiatus. But I'm reporting it here for the Googlers of the future.

 

That change was made on April 10, 2011 to the VI in Subversion. Not sure when the latest release of the ZLIB library was created by JGCode. It might have been just before that. On April 11, 2011 an additional change was made to also support Pharlap and VxWorks targets and on July 17, 2012 an additional change to support Windows 64 Bit (which is still irrelevant as the DLL is not yet released for 64 bit).

 

I have a lot of code changes on my local system mostly to support 64 bit but also some fixes to the string encoding problem but it is all in an unfinished state and I hesitate to commit it to the repository as anyone trying to create a new distribution library of that would create a likely somewhat broken library currently.

 

I'm also not exactly sure about the current procedure to create a new library release as well as the mentioned icon palette changes in the last release made by JGCode. I didn't see any commits of those changes to the repository. Otherwise I might have created a new release myself with the current code.

[ShaunR]

The way I resolved a similar issue was to use the "Path to Command Line String.vi" (which isn't on the palettes) rather than path to string then hacking the string. It seems to work on all platforms.

 

 

You can then just use all the path primitives (e.g. strip and build) to traverse the path without worrying about the underlying format.

Edited March 14, 2013 by ShaunR

[hooovahh]

The way I resolved a similar issue was to use the "Path to Command Line String.vi" (which isn't on the palettes) rather than path to string then hacking the string. It seems to work on all platforms.

 

path2string.png

 

You can then just use all the path primitives (e.g. strip and build) to traverse the path without worrying about the underlying format.

I've never heard of this primitive before, but I couldn't get your snippet to work.  I tried in 2012 SP1 but it just added it as an image (I first saved it to my PC locally then dragged it to the BD).  I opened the file in a PNG editor and I couldn't find the VI data inside.  Would you mind posting a VI file with that primitive in it? 

[ShaunR]

I've never heard of this primitive before, but I couldn't get your snippet to work.  I tried in 2012 SP1 but it just added it as an image (I first saved it to my PC locally then dragged it to the BD).  I opened the file in a PNG editor and I couldn't find the VI data inside.  Would you mind posting a VI file with that primitive in it? 

Here ya go.

[Darin]

You can just go to the source:

 

..LabVIEW xxxxvi.libAdvancedStringCommand Line String To Path.vi

[hooovahh]

You can just go to the source:

 

..LabVIEW xxxxvi.libAdvancedStringCommand Line String To Path.vi

I (incorrectly) assumed it was a primitive because of the icon, thanks. 

[Rolf Kalbermatter]

The way I resolved a similar issue was to use the "Path to Command Line String.vi" (which isn't on the palettes) rather than path to string then hacking the string. It seems to work on all platforms.

 

path2string.png

 

You can then just use all the path primitives (e.g. strip and build) to traverse the path without worrying about the underlying format.

 

That function does not do the same than what this VI does. For one the string part in the lvzip library is always in the unix form, while the other side should be in the native path format. Try to convert a path like /test/test/test.txt on Windows with this function. Of course you can replace all the occurrences of into / on Windows, in the resulting string, but that just complicates the whole thing.

 

I probably end up putting that entire function into the actual shared library function, since it also needs to do character encoding conversion too to allow to work with filenames containing extended ASCII (or UTF8) characters. And to make everything interesting the whole encoding is VERY different on each platform. The strings in the ZIP file are under Windows normally stored with the OEM charset while LabVIEW as a true GUI application uses everywhere the ANSI codepage. Basically they are both locale (country) specific and contain more or less the same characters but of course on different places! That is the reason that filenames containing extended characters look wrong when extracted with the lvzip library currently. On other platforms there isn't even a true standard with the various ZIP tools as to how to encode the filenames in an archive. It usually just uses whatever is the current locale on the system, which at least on modern Unixes is usually UTF8.

The ZIP format allows for UTF8 filenames too, but since on Unix most ZIP tools are programmed to use the current locale, they do store UTF8 names but do not set the flag that says so! Of course there are also many ZIP tools that still don't really know about UTF8 too so extracting an archive with them that was created with UTF names causes serious trouble.

 

Basically there is no absolutely correct way to make lvzip deal properly with all these things. My plan is to make it work such that for packing it uses only standard ASCI when the filenames don't contain any extended character and otherwise always use UTF8. For unpacking it will have to deal with the UTF8 flag and otherwise assume whatever is the current locale, which can and will go wrong if the archive wasn't created with the same locale than it is retrieved. On Unix there is no good way to support extraction of files with extended ASCII characters at all, unless I pull in iconv or iuc as a dependency.