Unzip files within labview

[Mads]

The plan is not to run it on the FPGA, just under RT on the RIO.

 The functions seem to be there already in LV, it's just that the unzip functionality does not work properly, so it does not seem that far fetched to get native support. As Devin tells in his message that's now been reported to RnD so perhaps in a future release we'll see it. From a cross-target compatibility standpoint it would be good to have, and it fails on Windows as well and is on the standard pallettes so it should definitely work there at least.

zlib is an option yes, for our use we'll probably end up just doing some simple G-based file packaging though.

[Mads]

If anyone else has the need to reduce a directory of files into a single file (the main job we used zip-compression for in this case) and do it in pure G then the attached code will do the trick.

It contains one VI ("Dir2File") that will make a file based on a directory (and all its contents, subdirectories and all), and a second VI ("File2Dir") that will recreate the directory based on that file. Written in LV 8.5.

No CRC and no compression though, that will have to wait for later...

Message Edited by Mads on 11-30-2007 08:26 AM

[Mads]

By using the Dir2File solution one might think - "Hey, why not use that to get a single file and then zip and unzip that file instead, the unzip function works on such archives so the problem is solved!", but although the zip VIs run on the RIO they return error 42 (both zip and unzip).

At least that's what I've been getting...if that's a different issue that can be solved then a combo of the Dir2File and zip/unzip would be a solution to the unwillingness of the unzip function to handle multi-file archives...

[kehander]

So neither the LabVIEW Zip functions nor the OpenG equivalents work on RT targets (i.e. Phar Lap), right?

I agree, this would be nice to have.  Isn't there at least a Zip utility that could be executed under Phar Lap through SysExec or something?

[rolfk]

---

kehander wrote:
So neither the LabVIEW Zip functions nor the OpenG equivalents work on RT targets (i.e. Phar Lap), right?

I agree, this would be nice to have.  Isn't there at least a Zip utility that could be executed under Phar Lap through SysExec or something?

---

As I wrote, anybody having the toolchain for the RT target installed should be able to create a version of the OpenG LVZIP library for that platform. the used zlib functions make only use of a few standard C library functions and therefore compilation of a DLL/shared library for that platform should be very straightfroward. Me not having such an RT target available (and no time at the moment) can't do that currently.

Rolf Kalbermatter

[Mads]

I just found out that there is a problem in the Dir2File VIs when they are run on the RIO...caused by the fact that if you convert a path to a string on the RIO it does not convert the same way it would on the PC(!).

This seems very strange as the paths are shown the same way when running on RIO, so why not the converted string as well?

Here is an example:

Conversion on Windows:

The path: c:\test\hello.txt 

becomes the text: c:\test\hello.txt

On RIO the path looks the same, however the text becomes:

/c/test/hello.txt

Now this is all fine as long as you are going to use the string on the RIO - there other functions understand that path fine, however if you take that path and use it on a Windows machine it fails. Why are paths represented in Windows-style all the time on the RIO, except when converted to text? The inconsistency is handled on the RIO, but not across to Windows. In this case we use relative paths from the RIO to rebuild a directory structure on Windows and it fails due to this.

The solution for Dir2File is simple enough - either code or decode the relative path correctly, or use a flattened path value instead (the latter might need testing)...I'll upload a fixed version later.

[Mads]

Attached is the Dir2File functions with the path fix.

The path to text conversion issue has been discussed on:

http://forums.ni.com/ni/board/message?board.id=280&message.id=2823&query.id=51989#M2823

I would say it would be more better to stick to either Windows or Unix style paths at all times, instead of mixing them like this..but off course once you know about it is easy enough to handle.

[Mads]

Surprisingly even the revised code did not work properly even though it does produce correct absolute paths from the relative ones.

Debugging showed that the way paths are handled on RIO is not just inconsistent, it is flawed. To discover this just take a path like

c:\Monitors\Test\Vibration and build a new one by appending Sensors\test.ini

The output of the Build path function is correct: c:\Monitors\Test\Vibration\Sensors\test.ini

Now wire that path to a Strip Path function...and what do you get?

c:\Monitors\Test\Vibration    (!)

Not the correct c:\Monitors\Test\Vibration\Sensors

The inconsistent path handling seems to have covered up a bug.

PS. In the case of Dir2File it seems best to have one set of functions for the RIO and one for the PC, just to make sure paths are handled correctly on both.

Message Edited by Mads on 12-05-2007 05:03 AM

[rolfk]

---

Mads wrote:

The plan is not to run it on the FPGA, just under RT on the RIO.

 The functions seem to be there already in LV, it's just that the unzip functionality does not work properly, so it does not seem that far fetched to get native support. As Devin tells in his message that's now been reported to RnD so perhaps in a future release we'll see it. From a cross-target compatibility standpoint it would be good to have, and it fails on Windows as well and is on the standard pallettes so it should definitely work there at least.

zlib is an option yes, for our use we'll probably end up just doing some simple G-based file packaging though.

---

I've looked into this a bit more and one possible problem might be the use of the C runtime library in MSVCRT.DLL for a default build of the DLL. I think the Pharlap based systems from NI only come with msvcp71/msvcr71 DLLs for the C runtime if at all. As I do not currently want to upgrade my Visual C installation to 2003 or higher it's a bit hard to create a shared library that could run with this. However I created a shared library that included the static C runtime from Visual C. This avoids the dependency on a specific external Visual C runtime DLL at the cost of extra DLL size. It also adds dependencies on extra kernel32.dll exports so this could be another problem as I have no way to check for the moment if this DLL would run on a Pharlap based RIO or Compact Fieldpoint system.

I've attached the static runtime version of the lvzip.dll to this post so someone can maybe try it out if a LVZIP VI referencing this DLL will now work on the Pharlap based RT target. This DLL should also just run fine on a normal Windows based system.

Rolf Kalbermatter

[Mads]

Dir2File where the File2Dir function for the RT-platform is different than the PC version to handle the interchange-problems with relative paths.