EricLarsen Posted November 12, 2009 Report Share Posted November 12, 2009 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. Quote Link to comment
PaulG. Posted November 12, 2009 Report Share Posted November 12, 2009 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. Quote Link to comment
Mark Smith Posted November 12, 2009 Report Share Posted November 12, 2009 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 Quote Link to comment
asbo Posted November 12, 2009 Report Share Posted November 12, 2009 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. Quote Link to comment
crelf Posted November 12, 2009 Report Share Posted November 12, 2009 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. Quote Link to comment
Rolf Kalbermatter Posted November 13, 2009 Report Share Posted November 13, 2009 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. Quote Link to comment
Ton Plomp Posted November 13, 2009 Report Share Posted November 13, 2009 It even got a CAR: 4EN2FI7U. Not that it ever shows up on a known issues/fixed issues list. Ton Quote Link to comment
mzu Posted November 13, 2009 Report Share Posted November 13, 2009 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 ... Quote Link to comment
Daryl Posted November 13, 2009 Report Share Posted November 13, 2009 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. Quote Link to comment
mzu Posted November 13, 2009 Report Share Posted November 13, 2009 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 ... Quote Link to comment
EricLarsen Posted November 13, 2009 Author Report Share Posted November 13, 2009 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. Quote Link to comment
Rolf Kalbermatter Posted November 16, 2009 Report Share Posted November 16, 2009 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.