Jump to content

oglib_lvzip installation error


jgcode

Recommended Posts

Howdy!

 

Hope all is well. Love the new VIPM 3.0 - sure is fast! :)

 

I am chasing some support for the following issue:

 

post-2618-1258340555_thumb.png

 

I have had trouble installing the oglib_lvzip package. It all seemed to happen around the time 2009 and 2.5.1-2 came out. I have seen this issue across VIPM 2.03 and VIPM 3.0 and on all current Win x86 OS' (XP/Vista/7) and on a couple of different LabVIEW versions (2009 and 8.2.1) and also across package versions too (2.1 to 2.5.1-2).

 

I can see here that other people may have had it, and I tried the suggested workaround with no luck. I can also see that the error I am seeing may be a false description.

 

Additionally I have had it work as well on the cases mentioned above too on different PCs!!

 

I have seen other packages do this namely the dynamic palette but then I managed to get that to install.

 

Anyways, I was finally successful in developing a workaround today - I reverse engineered the package and found that the install scripts were the cause of the issue. With them removed the package installs just fine.

 

post-2618-1258340823_thumb.png

 

Now here comes the weird part. If you have opened the scripts you can see that no code is actually called for the Windows NT case! But these are the cause of the error.

 

Has anyone seen this? It has driven me crazy for a while now and I am glad I have a work around. Can anyone explain this?

 

I would like to upload the package, but it is above the upload threshold. I hope it is ok and not disrespectful to the authors for me to re-package it, but I do so in an event to discover the cause of the error.

 

Cheers

 

JG

Link to comment
Share on other sites

Just got the same error on Windows 7; VIPM 3.0; html help common and dynamic palettes packages

 

LV8.6.1

 

post-2618-1258356480.png

 

LV8.5.1

 

post-2618-1258356465.png

 

 

Everything else installs ok, these two packages have scripts therefore, rather then the script itself causing an error, could it be the act of running a script? Could windows be blocking something (permissions wise) when it goes to run??? Seems weird LabVIEW 2009 worked for these two.

 

 

??

Link to comment
Share on other sites

Hi jgcode,

 

Sorry for the delay in response.

 

It seems to me that this error is occurring when VIPM tries to extract (unzip) the script VIs from the package into the temporary folder (prior to executing them, which never actually happens, due to the error).

 

The only thing that I can think of is that there is some file permissions issue affecting things. For example, the file already exists in the temp directory but VIPM does not have permission to overwrite it.

 

Can you please look inside your temp directory (C:\Users\{YOUR_USERNAME}\AppData\Local\Temp) and see if you can find any of the following VIs:

  • PreInstall.vi
  • PostInstall.vi
  • PreUninstall.vi
  • PostUninstall.vi

If you find any of these, could you please check their permissions? For example:

  • Are they read-only?
  • Who is the owner?
  • Does your user account have any permission to write to these files?

Thanks for your help in debugging this. Hopefully, we'll get to the bottom of it.

 

-Jim

Link to comment
Share on other sites

Sorry for the delay in response.

 

The only thing that I can think of is that there is some file permissions issue affecting things. For example, the file already exists in the temp directory but VIPM does not have permission to overwrite it.

Hey no worries, it's cool because because I can now confirm 100% that this is the problem :)

 

I have attached a culprit - some subVIs might be missing but you should be able to check the permission etc.. if you want to.

Here is a summary:

  • Are they read-only? Yes
  • Who is the owner? My PC
  • Does your user account have any permission to write to these files? It seems it does

Bug Report

Fix For: VIPM 3.0; VIPM 2.0.3

Computer: Windows 7 Professional x86, P4 3.2GHz, 2GB RAM.

Steps to reproduce -

1. Create two VIPM packages that contains post install scripts:

a. The first generates an error which is output to the error out terminal of the script (error package).

b. The second does not generate an error which is output to the error out terminal of the script (no error package).

2. Install the error package.

3. Install the no error package.

What you expected to see - VIPM will fail to install the error package. The post install script will be deleted from the temp directory. VIPM will successfully install the no error package.

What you saw instead - VIPM fails to install the error package. The post install script will stay in the temp directory. VIPM fails to install the no error package returning the LVZIP Error Code 8.

 

As a workaround I can clear all errors at the end of the script to prevent this.

 

Thanks for your help in debugging this. Hopefully, we'll get to the bottom of it.

No, thank you, I am back to building packages and can continue enjoying VIPM 3.0 !!

 

PostInstall_jki__LV82_.vi

[LabVIEW82]

Link to comment
Share on other sites

OK, great. I'm glad that the work-around helped you get back up and running :)

 

However, I'm a little concerned that this issue (which was supposed to be fixed in 3.0) is not fully resolved:

Are you still able to reproduce the issue? Would you mind sending me (off-line if that's better for you) the offending package (that generates the error). This would help me debug the root problem.

 

Thanks,

Link to comment
Share on other sites

OK, great. I'm glad that the work-around helped you get back up and running :)

 

However, I'm a little concerned that this issue (which was supposed to be fixed in 3.0) is not fully resolved:

Are you still able to reproduce the issue? Would you mind sending me (off-line if that's better for you) the offending package (that generates the error). This would help me debug the root problem.

 

Thanks,

 

Sorry I didn't go back and check the known issues before posting which I should have done (I was way too excited about it working).

Yes, you are correct on that - my original bug report is wrong.

 

If I pass a simple error through to the error out terminal then VIPM seems to be able to handle that just fine.

This package is unique!!

Although clearing the error does get it to work ok.

 

I don't mind sending package if it can help out, so I have emailed the project so you can easily remake packages for testing.

Look forward to your thoughts on why this script cannot be overwritten in temp.

 

Cheers

JG

Link to comment
Share on other sites

Sorry I didn't go back and check the known issues before posting which I should have done (I was way too excited about it working).

Yes, you are correct on that - my original bug report is wrong.

 

If I pass a simple error through to the error out terminal then VIPM seems to be able to handle that just fine.

This package is unique!!

Although clearing the error does get it to work ok.

 

I don't mind sending package if it can help out, so I have emailed the project so you can easily remake packages for testing.

Look forward to your thoughts on why this script cannot be overwritten in temp.

 

Cheers

JG

 

OK, I was able to reproduce your error with the package you sent me. When I get a spare moment, I'll try testing this while running VIPM from source and I should be able to quickly find and fix the issue. I'll keep you posted.

 

Thanks,

Link to comment
Share on other sites

I was able to figure out what was going on when testing from VIPM source code. There we a couple issues:

 

1) the script VIs extracted into the temporary folder were not being deleted when they generated an error.

2) existing script VIs in the temporary folder were not able to be overwritten if they were read only.

 

This will be definitely be fixed in a future release :)

Link to comment
Share on other sites

I was able to figure out what was going on when testing from VIPM source code. There we a couple issues:

 

1) the script VIs extracted into the temporary folder were not being deleted when they generated an error.

2) existing script VIs in the temporary folder were not able to be overwritten if they were read only.

 

This will be definitely be fixed in a future release :)

 

Great to hear you identified the problem!

Thank you for your great support.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.