Can't eject USB disk

[EricLarsen]

Has anyone else run into an issue where Windows won't let you eject a USB flash disk if you've been reading files off of it into Labview? I often use my USB disk to transfer files between the lab and my office for analysis, and a lot of times I'll have to quit Labview before I can eject the disk.

It seems that Labview is holding on to a directory handle when maybe it shouldn't be. I was able to see that using Process Explorer. In the first example, I dragged and dropped the file name into the file path control and ran the code. Labview opened up one file handle to the file, and released it when Close File was executed. At this point I could successfully eject the USB disk

In the second example, I used the Browse button on the front panel control to select the file. Labivew opened up two handles, one to the file and one to the directory the file was in. When Close File was executed, only the handle to the file itself was closed, the handle to the directory remained open. I was unable to eject the disk until I quit Labview. Anybody seen this before? Is there anyway to force Labview to close the handle to the directory so I can eject the disk?

I'm using 2009, but I'm fairly certain I've seen this in earlier versions.

[PaulG.]

Yes. I see it all the time. Maybe it's risky but I just swear under my breath and take the USB drive out anyway.

[Mark Smith]

Don't have any workarounds or explanations, but I can confirm that LabVIEW can be pretty annoying in the way it gets handles and never seems to let them go until you close LabVIEW. This behavior has been around as long as I can remember. I usually see it when I want to delete a folder that LabVIEW has accessed at some time and I can't do it until LabVIEW has closed.

Mark

[asbo]

A lot of programs tend to do this. I don't think I've ever run VIs off a USB drive before, but you might try using Unlocker or LockHunter to invalidate those handles if closing out LabVIEW is becoming a hassle for you. It *might* cause LabVIEW to crash, so always commit changes to disk before messing around with file/folder handles.

[crelf]

It's a common issue, and it's not just limited to USB drives - sometimes if you edit a VI, save it, and get LabVIEW back to the "Getting Started" window, then try to delete the folder that the VI is in Windows won't let you - the workaround is to fully close LabVIEW.

[Rolf Kalbermatter]

It's a common issue, and it's not just limited to USB drives - sometimes if you edit a VI, save it, and get LabVIEW back to the "Getting Started" window, then try to delete the folder that the VI is in Windows won't let you - the workaround is to fully close LabVIEW.

I've seen it too many times but it seems to be mainly limited to using the Browse dialog. Normal LabVIEW File I/O primitives usually don't seem to cause that problem. That made me believe that it is something the Browse Dialog is causing and this dialog is largely part of the OS itself. Maybe it's the way LabVIEW is using that dialog.

An interesting experiment I wanted to do in ages is to use the LabVIEW file dialog instead and see if the problem persists. Problem is that I have not found a reliable way to reproduce that problem.

[Ton Plomp]

It even got a CAR: 4EN2FI7U.

Not that it ever shows up on a known issues/fixed issues list.

Ton

[mzu]

For what I noticed it happens when the current working directory of any program is set to the USB drive. Open File Dialogue apparently does change it. I just open some file from my HD ...

[Daryl]

It's a common issue, and it's not just limited to USB drives - sometimes if you edit a VI, save it, and get LabVIEW back to the "Getting Started" window, then try to delete the folder that the VI is in Windows won't let you - the workaround is to fully close LabVIEW.

This has been my experience as well.

[mzu]

It's a common issue, and it's not just limited to USB drives - sometimes if you edit a VI, save it, and get LabVIEW back to the "Getting Started" window, then try to delete the folder that the VI is in Windows won't let you - the workaround is to fully close LabVIEW.

Or to open a VI from another location ...

[EricLarsen]

Or to open a VI from another location ...

Yep, that does it. Using the path control's browse button to open a data file on the local drive redirects Labview's file handle away from the USB disk. Then the USB can be ejected.

I wonder if there is a work around that can programmatically force Labview to redirect that file handle away from the USB disk. When I get a chance I'll play around and see if I can work something out.

[Rolf Kalbermatter]

Yep, that does it. Using the path control's browse button to open a data file on the local drive redirects Labview's file handle away from the USB disk. Then the USB can be ejected.

I wonder if there is a work around that can programmatically force Labview to redirect that file handle away from the USB disk. When I get a chance I'll play around and see if I can work something out.

Unfortunately that is a functionality of the Windows shell File Dialog. On a successful file selection it seems to set the current directory for the app to the directory that selection was made in. Why in the world the MS programmers thought this to be a good idea, I do not know at all. There seems no way for an application to tell the dialog not to do that. The only LabVIEW workaround would be to keep resetting the current directory to the previous value after each dialog! possibly breaking something that was the cause for MS to add that functionality.