Automatically close file references

[gsussman]

A new feature that would act similarly to the "Automatically close VISA sessions" option and close all open file references once the top level VI has stopped running.

This new function would preclude the situation where LabVIEW locks, and keeps a file locked until the entire development environment is closed.

(I would even be happy with a menu option to explicitly close all open file references.)

The primary use case would be during development/debugging. If you stop or abort your top level VI without closing a file reference, LabVIEW will hang on to the reference keeping it open, but inacessable, until the dev environment is shut down.

It seems that if there is not an open reference to the file on the block diagram or the top level VI has stopped running, and certainly when all open VIs are closed, then all files should be closed and locking handles should be released.

I suppose this concept could be expanded to cover any reference type that LabVIEW does not implicitly close when the top level vi goes idle.

[AristosQueue (NI)]

When the top-level VI stops running, LV already automatically closes file references. This happens even if the VI gets aborted. Can you post a VI that shows the current behavior and then comment on what you would like to see changed? The way your idea reads currently, I would say it should be closed as already implemented.

> I suppose this concept could be expanded to cover any reference type

> that LabVIEW does not implicitly close when the top level vi goes idle.

Every refnum type that ships with LV itself (ie., what you get when you install LabVIEW and choose not to install the driver DVD) does do automatic closing when the top-level VI goes idle. My understanding is that nearly all of the driver refnums also do automatic closing, though there are a couple I've heard of but never used that are explicitly documented not to close, but they are definitely the exception.

[tst]

AQ, I agree with your post, but I can also say that LV has has a tendency to open handles to files opened by other applications (I see this in 2009). Maybe the OP has a similar situation?

I can't offer proper repro steps, but it often happens that I try to delete a file and can't because LV opened a handle to it even though it's a file which has nothing to do it. This might have to do with how Windows Explorer handles files you double click, but like I said, I have no read idea what causes this.

[gsussman]

tst....this is the issue I was hoping to address.

From time to time (normally I see this when debugging) LV will grab a file (often times it is not a LabVIEW specific file but rather a data or log file). Using a tool like Unlocker, I can see that it is LabVIEW.exe that has the locking handle, but I don't have any VIs currently running.

I had assumed (possibly incorrectly) that LV was not closing the file reference when the top level went idle or that some file reference was opened then orphaned with no real owner. Based on AQ's post, it looks like the issue might be something else.

As far as I can rembember, LabVIEW has had this behavior.

[AristosQueue (NI)]

This is outside my primary knowledge area, but it sounds more like a bug than an intended feature. If you can put together VIs that reproduce this situation, I think posting it to an AE to investigate is worthwhile.

> As far as I can rembember, LabVIEW has had this behavior.

Doesn't mean we intended it. Doesn't mean it can't be changed. 🙂

[GregR]

It is intended behavior that any files opened with our builtin file nodes should be closed when the top level VI becomes idle. If you are using some other API to access files, then that is a different matter. If the file open calls are in DLLs, then they may not be hooking into LabVIEW's cleanup system so that they are notified of aborts.

Do you think this happens with the normal file I/O nodes or are you using other file APIs?

[SteveChandler]

I think I know what the original poster is getting at.

Open LabVIEW with no projects or vi's open.

Create a new folder with Windows Explorer.

Create a new project and save it to the new folder.

Close the project.

LabVIEW is still open but no projects or vi's are open.

Using Windows Explorer try to delete the folder created for this test. Can't. You can delete the files in the folder but not the actual folder.

I think I have seen this with individual files but could be wrong.

LabVIEW 2010 32 bit Windows 7 64 bit

[Technico]

I 've seen this before, but I can not find a link to that topic very quickly.

When saving a vi/project you browse to a folder and for some reason LV sets the last browsed folder as the (Set)CurrentDirectory (windows: kernel32.dll) and that's why this can't be deleted.

Just open a vi that is located in another folder and notice that the previously locked folder is not in use anymore.

[AristosQueue (NI)]

That behavior is locking of the directory, not a file. The original post was talking about file refnums. I don't think these are the same issue.

[GregR]

---

@SteveChandler wrote:

Open LabVIEW with no projects or vi's open.

Create a new folder with Windows Explorer.

Create a new project and save it to the new folder.

Close the project.

LabVIEW is still open but no projects or vi's are open.

Using Windows Explorer try to delete the folder created for this test. Can't. You can delete the files in the folder but not the actual folder.

---

As was mentioned, this specific behavior is a working directory issue and is not related to any refnum that LabVIEW manages. In fact LabVIEW is not even the one setting the working directory. The native Windows file dialog does this. You can see this same behavior in other programs that use the real Windows file dialog as well. We have considered trying to stop the file dialog from doing this, but that starts getting in the way of other functionality in the dialog. 

gsussman, do you think this is the behavior you were having trouble with or do you think there is a case where diagram references are not being properly released?

[gsussman]

I believe that the setting of the working directory is the issue I saw.