LabVIEW won't allow programmatic deletion (LabVIEW 2011)

[DonRoth]

Have you run across a situation where binary file reference has been closed but LabVIEW will not allow programmatic deletion using the DELETE fx?  If so, how have you solved it?

[tst]

Not specifically for that, but there were cases where editing operations cause LV to keep an open handle to a file. One method would be to delete the file, but if that's not an option, I would suggest looking for tools to close handles. A quick search shows these two and I'm sure there are more, some of which can be called programmatically:

http://www.jwgoerlich.us/blogengine/post/2007/01/28/Viewing-and-releasing-file-handles.aspx

http://superuser.com/questions/93567/removing-locks-on-files-in-windows-7

[DonRoth]

This is a binary file that was created in LabVIEW.  In the subVI just preceding the subVI in which deletion occurs at the end of the subVI (everything properly ordered through error cluster connecting), I have verified that all references are closed.

I extracted all of the code to a new VI diagram, and the deletion works just fine.

I am starting to wonder if somehow the block diagram of the original VI has been corrupted causing this very strange behavior.  We had an automatic reboot in the middle of the night while my code was doing an overnight run.  I have seen situations where VI settings change when something like this happens.

I just added some code to the original VI where I do a test where I verify the existence of the file, I open it, I close it, then delete it.  I still get error 5 !! 'File Already Open'.   How is this possible if I am explicitly closing the file?  There somehow has to be a reference to the file that is still open.

[tst]

I don't have that much experience with playing with file references directly, but you should start by confirming exactly where the error comes from. Is the error reproducible? I suppose in theory it's possible that the OS doesn't actually close the file handle inside the close primitive but does it in its own time (although I would expect that it would be inside the function), but I don't have anything concrete to support that.

Can you use another program to look at open handles to the files, to see if they remain open?

[DonRoth]

The error occurs right after the 'Delete' fx is executed.  I have done execution highlighting to verify this.  The error is reproducible.  I will keep staring at this.

Don

[tst]

Can you upload a VI which reproduces the problem?

Also, instead of staring at it, how about trying what I suggested earlier (look at the handles, see when they're created and when they're destroyed).

[DonRoth]

I am not sure I can reproduce with a simplified VI.   The subVI runs just fine and performs deletion as it should when not called from the main program (and the main program closes all references prior to entering the subVI).  I would have to create a simplified main program somehow, and the main program is very complicated.

I have downloaded 'Process Explorer' to at least try to view the handles.

Don

[DonRoth]

So using Process Explorer, it appears that LabVIEW does not want to let go of the references until the program stops (even though I even tried putting in an explicit [and what should be unnecessary] file close operation (see about 5 posts up).

The files with 'COPV' prefix are the ones I need to close and delete.  They are large temporary files that need to go away.  So another strategy I am thinking of is to use the Windows temporary folder for these files, thinking they will be deleted automatically when the program closes.  Thoughts?

Don

[tst]

Files from the temporary folders aren't deleted automatically, but only when a cleanup operation is performed. What I would suggest is that you create your own folder inside the temp folder for your files and then delete everything inside that folder on program load.

[DonRoth]

Hello tst -

Thanks for taking your valuable time to help me with this problem.  As I had stated in prior posts, the subVI itself when tested alone performed the deletions.  Therefore the problem had to be somewhere in my main program.  My main program is fairly complex and involves decoding a very complicated data format.  In that decoding process, I ended up having to run through a loop twice that is embedded deeply in the code.  By running through the loop twice, I was inadvertently creating two instances of the same file.  So even though I properly closed the references, there were still references open pertaining to those I had mistakenly created a second time.

This was a tough one to figure out and by having someone to bounce thoughts off of, I was able to come to the proper solution without having to use a brute force solution.  Such is the value of these discussion forums.

Again, I appreciate your time.

Sincerely,

Don