Files end up as directories in zip archive

[Mads]

LabVIEW 2017 with OpenG Zip Tools 4.1.02 on cRIO-9030 (Linux RT target).

I had a piece of code developed in LabVIEW 2015 for a cRIO-9030 where a folder is compressed with the Zlib Compress Directory function, and it has worked for years...Now I converted it to LabVIEW 2017, and for some reason any files (lots of .ini files) in the directory will now end up as folders. What is even stranger is that if I debug I can see that the files are detected as files as they should by the zlib file information VI. I seem to remember having run into a similar issue a long time ago, but I cannot remember what the solution was..

Or perhaps it is a new issue on 2017? I'm in a bit of a hurry so I'm throwing out a question here just in case I get a response before I've spent more time on it...Any ideas?

[Jim Kring]

I don't have a quick answer for this one. I'm curious about it...

[Mads]

It seems as far as I've established so far that everything that gets passed on to the linked library calls are the same on the Linux target as on Windows, (the file attributes e.g. are calculated to be 0) but the resulting file has minor changes (attribute flags I presume; I have not gotten into the details of the format yet) in the first and last lines of the archive. Otherwise the content is identical (in other words the files are there, but incorrectly identified as directories so I do not get to their content).  Perhaps it has never worked on these Linux RT targets :-O I hope I'm wrong.

I know the deflate/inflate works on Linux RT targets, but discovered now that for the directory compression a different method had been put in place at some point in time for the cRIO-9030, so I was wrong when I said it had worked before...It was, it seems, just due to an override on those targets.

[Rolf Kalbermatter]

How do you look at those ZIP files? Through the OpenG library again or a Unix ZIP file command line utility?

[Mads]

I copy them to a Windows computer and open them there with Explorer.

I just reduced this down now to compression of a single file on a cRIO-9030 with LabVIEW 2015. The input and output files, plus the source (just the top level) is included in the attached file.

Zip test.zip

 

I've also attached a capture of the subVI front panels in the call chain, if that might offer any clues.

Edited June 30, 2017 by Mads
Added picture

[Rolf Kalbermatter]

Thanks I'll have a look at this over the weekend.

EDIT:

I did have some look at this and got the newer code to work a bit more, but need to test on a real x64 cRIO system. Hope to get my hands on one during this week.

Edited July 2, 2017 by rolfk

[Rolf Kalbermatter]

Haven't forgotten this but there needs to be some more work done as I also updated the whole source code of the shared library in the past and I need to do some more tests. But for now I'm taking off for some well deserved vacation.

[Mads]

Any news on this Rolf?

[Mads]

The problem does not seem to be Linux RT as such, but the cRIO-9030 - so probably the fact that it is x64.

I took the same code and ran it on a cRIO-9063 (ARM) which also runs Linux RT, and it works as it should. 

 

Edited September 26, 2017 by Mads

[Rolf Kalbermatter]

I figured as much as I did try on a myRIO and also on a normal Linux x86 system and couldn't reproduce the problem. I do have currently a 9035 available for another project (which has higher priority) and will try it on that one as well very soon.

[hooovahh]

It's somewhat non-trivial to setup.  But you can create an x86 based Linux RT VM to test this type of thing.