How can I repair a Generic file I/O error on opening a vi?

[SciManStev]

I tried to open a vi while the folder the vi is in was being coppied to a backup location. I got a Generic file I/O error, and the vi wouldn't load. After the copy process completed, I rebooted, and tried again to load the vi. It still failed, so I tried to load the backup file, and it also could not be loaded. Is there anything I can do to save this file? I recently put a lot of work into it, and the working backup I do have is before any of the new work took place.

Thanks

[JordanG · Accepted solution]

Are you able to open the VI at all? If you can open it, try copying the block diagram into a new, blank VI. Most likely the VI has become corrupted and pasting into a blank VI and resaving can fix the corruption.

Unfortunately if LabVIEW closes upon trying to open the VI and you are unable to access the block diagram, then it has become corrupt. There is no way to recover the VI or to extract certain parts of the VI from the file. The only solution is to start with a blank VI and reprogram the corrupted VI again. You may consider running a file recovery scanner on your PC to see if there is any part of it that is recoverable. Though it seems you will have to use your backup version.

Jordan G

[SciManStev]

Thank you! I was afraid of that, but I had to try anyway.

[leo_mattam]

Could you open the vi? I am facing similar situation and dont know what to do..

[SciManStev]

The only thing I could do, was open a much older copy, and redo all the work. I lost quite a lot of time, but I learned to never try to open a vi while it was being coppied somewhere else. I regularly back up my vi's, and just sit idle until the copy is finished, or have the vi open before the copy starts and not try to save until it is finished. Another area to stay away from is trying to do something else when a vi is compiling for an executable. It is OK to do something else when an installer is created, but not when a vi is compiling.

[leo_mattam]

I just restarted with an old one. Anyway learned a big lesson.
Thank you for your valuable time.

[michael-doebert]

Hi together,

If got a big big issue with this problem and I don´t know how it could occur.

The biggest problem is, that i have no older copy of the program and it toke a lot of time to build it.

Is there another way to fix the problem with this error?

Thanks a lot

[GerdW]

Hi michael,

i have no older copy of the program and it toke a lot of time to build it.

So you have learned to create backups at regular intervals or even better use some SVN system?

The biggest problem is…

missing backups or SVN repositories!

Is there another way to fix the problem with this error?

When the VI file is broken you need to get a backup or check out from your SVN system!

[niallmartin10]

Just as small side note.  I had this same issue, and it turns out the issue was the filepath was too long.  As soon as I copied it to my C drive and opened it, there was no problem.

Maybe worth a try

[billko]

---

@niallmartin10 wrote:

Just as small side note.  I had this same issue, and it turns out the issue was the filepath was too long.  As soon as I copied it to my C drive and opened it, there was no problem.

Maybe worth a try

---

These issues happen more often with LabVIEW because we often have a few nested folders and large file names as part of our self-documentation.  That, combined with a long server name and long path to your network folder can lead to trouble.  I'm not saying it's a LabVIEW problem, but sometimes an honest implementation of LabVIEW best practices can have unexpected ramifications.