Jump to content

Can't eject USB disk


Recommended Posts

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.

post-7727-125806104433_thumb.png

post-7727-125806104905_thumb.png

Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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 ...

Link to comment

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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