Jump to content


Photo
- - - - -

Cannot move or delete folder while LabVIEW is open


  • Please log in to reply
22 replies to this topic

#1 Shaun Hayward

Shaun Hayward

    Very Active

  • Members
  • PipPipPip
  • 145 posts
  • Location:Boston, MA, USA
  • Version:LabVIEW 2013
  • Since:2003

Posted 26 February 2010 - 10:30 PM

I remember reading something about this a while back but cant seem to dig is up with the search....

I'm running into an issue whereby browsing to a file in a LabVIEW path control seems to stop me from deleting that folder from any other part of my program until (a) LabVIEW is closed, or (b) I browse to a new path with the control in question.

As I said, I remember reading something, somewhere about the fact that LabVIEW keeps its current directory open (and therefore undeleteable) but I guess what I really need to do is point LabVIEW to a different current folder so I can delete the folder in question.

Any ideas?

PS. If it helps, my use case is this:
1. User has a data folder with a database file and a whole bunch of subfolders containing data thats too large for me to want to put in a DB record (such as hi-res images).
2. A User picks one of the files within the folder hierarchy to display in LabVIEW.... file is openned (file is also closed afterwards) and image data is displayed in a picture control.
3. User now decides that they want to move this entire dataset do wants to delete the database file and all associated content.
4. the LabVIEW move file/folder VI generates an error because it does not have permission to move the file
5. Trying to move the file in explorer also fails until LabVIEW either has a path control value change (using the browse button), or LabVIEW exited.

#2 Ton Plomp

Ton Plomp

    How many lines per hour? Zero!

  • Members
  • PipPipPipPipPipPip
  • 2,005 posts
  • Location:New Zealand
  • Version:LabVIEW 2012
  • Since:2000

Posted 27 February 2010 - 09:36 AM

NI claims this is caused by Windows. The OS has for every application an 'active folder'. Which is locked until the app is closed. It might help to open a file in another folder (without a browse dialog).

Ton

#3 Aristos Queue

Aristos Queue

    LV R&D: I write C++/# so you don't have to.

  • Members
  • PipPipPipPipPipPip
  • 2,805 posts
  • Location:Austin, TX
  • Version:LabVIEW 2011
  • Since:2000

Posted 27 February 2010 - 06:32 PM

It might help to open a file in another folder (without a browse dialog).

Yes, that does indeed help. Whatever the last directory you opened or saved a VI into, that's the directory LV holds locked. Open or save into any other directory to move the lock. Or close LV.

#4 Yair

Yair

    Extwemely Active

  • Members
  • PipPipPipPipPipPip
  • 2,749 posts
  • Version:LabVIEW 2009
  • Since:2003

Posted 28 February 2010 - 04:20 PM

What really annoys me is when LV grabs onto files which were opened by completely separate applications. Examples I remember are MP3 or AVI files which I opened with Media Player Classic (by double clicking them in an Explorer window) and then for some reason LV opened one or more handles to them, thus preventing their deletion (I saw it's LV by using a third party program and by the fact that I can delete them immediately after I close LV).

The main problem is that I can't reproduce this reliably. I have no idea what's causing it. AQ, is it worth reporting such a thing?

#5 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,407 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 28 February 2010 - 10:50 PM

What really annoys me is when LV grabs onto files which were opened by completely separate applications. Examples I remember are MP3 or AVI files which I opened with Media Player Classic (by double clicking them in an Explorer window) and then for some reason LV opened one or more handles to them, thus preventing their deletion (I saw it's LV by using a third party program and by the fact that I can delete them immediately after I close LV).


Glad someone else has seen this, I thought I was going insane when this was happening! :wacko:

#6 Aristos Queue

Aristos Queue

    LV R&D: I write C++/# so you don't have to.

  • Members
  • PipPipPipPipPipPip
  • 2,805 posts
  • Location:Austin, TX
  • Version:LabVIEW 2011
  • Since:2000

Posted 28 February 2010 - 11:34 PM

The main problem is that I can't reproduce this reliably. I have no idea what's causing it. AQ, is it worth reporting such a thing?

I've never dug into it... it never bothered me. Might be easy to fix if someone tried to fix it. So, yeah, go ahead and report it.

#7 neBulus

neBulus

    LV Survivalist

  • Members
  • PipPipPipPipPipPip
  • 1,389 posts
  • Version:LabVIEW 2009
  • Since:2009

Posted 01 March 2010 - 01:32 PM

I've never dug into it... it never bothered me. Might be easy to fix if someone tried to fix it. So, yeah, go ahead and report it.




I reported that bug and gave up trying to fight for it being a bug since other software (other than LV) does not do that. If you get the fixed great.

Ben

#8 PJM_labview

PJM_labview

    The 500 club

  • JKI
  • 762 posts
  • Version:LabVIEW 2009
  • Since:1998

Posted 01 March 2010 - 04:51 PM

Adding my 2c here.

I think I have experienced a lot more locks in LabVIEW 2009 than in previous LabVIEW version. I have a utility allowing me to bypass the lock and erase the file (or folder), unfortunately this is no longer working well (if at all) with LabVIEW 2009 locks.

PJM

#9 Shaun Hayward

Shaun Hayward

    Very Active

  • Members
  • PipPipPip
  • 145 posts
  • Location:Boston, MA, USA
  • Version:LabVIEW 2013
  • Since:2003

Posted 01 March 2010 - 06:20 PM

Is there any way to programatically point LabVIEW's lock elsewhere (ie without poping up a file browse dialog)?

#10 Yair

Yair

    Extwemely Active

  • Members
  • PipPipPipPipPipPip
  • 2,749 posts
  • Version:LabVIEW 2009
  • Since:2003

Posted 02 March 2010 - 04:16 PM

I reported that bug


Any details on that (when was it, CAR #)?

#11 neBulus

neBulus

    LV Survivalist

  • Members
  • PipPipPipPipPipPip
  • 1,389 posts
  • Version:LabVIEW 2009
  • Since:2009

Posted 02 March 2010 - 04:42 PM

Any details on that (when was it, CAR #)?


"

From my post of 3 Dec 2008
...

46949

Since that number looks funny it was given to me on SR# 1290801.



This is supposed to document an issue where LV does not always close files when it returns to the splash screen. I have to close LV completely before I can delete the directory where I was working. The note from the PSE passed to me from the AE was;



1- The PSE said the root cause of this behavior is due to Windows:

"Windows is updating the application's working directory when the file dialog is called. This can be easily tested by opening another VI/ project at a different path and then rename/move the original project (which should work). "



...



"

Ben

#12 Yair

Yair

    Extwemely Active

  • Members
  • PipPipPipPipPipPip
  • 2,749 posts
  • Version:LabVIEW 2009
  • Since:2003

Posted 02 March 2010 - 04:51 PM

OK, that's the original issue, NOT the one I was talking about. I guess it needs to be reported separately.

#13 Daklu

Daklu

    Bringing the Fu to you

  • Premium Member
  • 1,830 posts
  • Location:Seattle
  • Version:LabVIEW 2009
  • Since:2006

Posted 02 March 2010 - 10:40 PM

Here is my solution to this frequent annoyance.

1- The PSE said the root cause of this behavior is due to Windows:

"Windows is updating the application's working directory when the file dialog is called. This can be easily tested by opening another VI/ project at a different path and then rename/move the original project (which should work). "

While it may be the windows api lock that is preventing the folder from being deleted, I think the root of the problem is how the LV code uses the api. Think about what would happen if windows did allow a working directory to be deleted out from under an application. Every time the application reads or writes from the working directory the application would have to first check to make sure the directory exists. I don't think that's a very good solution.

It's not terribly difficult to store the current working directory in a variable and set the working directory to something like the root Labview folder. When the user initiates an action that uses the working directory such as the Open File dialog box, retrieve the previous working directory from the variable and use the windows api to set the working directory before calling the open dialog. Or better yet, don't use the OS working directory at all as part of the UI.


Certified LabVIEW Architect
Dak's First Law of Problem Solving: If the solution looks simple, I don't know enough about the problem.

Yes, the QSM is flexible. So is Jello. That doesn't make it good construction material.

There are two secrets to success:
Secret #1 - Never tell everything you know.


#14 rolfk

rolfk

    LabVIEW Aficionado

  • Premium Member
  • 2,320 posts
  • Location:Netherlands
  • Version:LabVIEW 2011
  • Since:1992

Posted 09 March 2010 - 07:20 AM

*
POPULAR

Is there any way to programatically point LabVIEW's lock elsewhere (ie without poping up a file browse dialog)?


Calling the SetCurrentDirectory() Windows API with a path you do not mind to be locked. The issue is that the Common File Dialog function in Windows sets this to the current path whenever it is dismissed with an OK click. So yes it is really a Windows issue. It happens with other applications too, that use the Common File Dialog but you rarely run into that issue there, at least I don't.

The actual API seems to have a flag OFN_NOCHANGEDIR that prevents Windows from changing the current directory if the user browses to a different directory during the dialog, but it is not supported before Vista. So NI still would have to inmplement a workaround around the Common File Dialog call, which admittedly shouldn't be difficult, but it may have implications in areas nobody is thinking about at the moment.

The other issue with files being locked by LabVIEW that another application opened I'm flabbergasted. Never saw that happen so far.

  • neBulus, crelf, Aristos Queue and 1 other like this

#15 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,407 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 09 March 2010 - 09:51 AM

The other issue with files being locked by LabVIEW that another application opened I'm flabbergasted. Never saw that happen so far.


Well LabVIEW locked files that where in my Recycle Bin today... weird.

#16 crelf

crelf

    I'm a LAVA, not a fighter.

  • V I Engineering, Inc.
  • 5,778 posts
  • Version:LabVIEW 2014
  • Since:1993

Posted 09 March 2010 - 03:34 PM

Calling the SetCurrentDirectory() Windows API with a path you do not mind to be locked.

IMHO: There's a post that deserves a kudos!

crelf

 

 

Copyright 2004-2014 Christopher G. Relf. Some Rights Reserved.  This posting is licensed under a Creative Commons Attribution 2.5 License.


#17 Yair

Yair

    Extwemely Active

  • Members
  • PipPipPipPipPipPip
  • 2,749 posts
  • Version:LabVIEW 2009
  • Since:2003

Posted 09 March 2010 - 04:17 PM


The other issue with files being locked by LabVIEW that another application opened I'm flabbergasted. Never saw that happen so far.


It happens occasionally, but the only way to notice it is to try to move or delete the file which is locked, so you won't notice it if you don't do that. The main problem is that I have no idea what's causing it. This is on Win XP SP3, LV 2009. I think it also happened with LV 7.0, but I'm not sure.

#18 rolfk

rolfk

    LabVIEW Aficionado

  • Premium Member
  • 2,320 posts
  • Location:Netherlands
  • Version:LabVIEW 2011
  • Since:1992

Posted 10 March 2010 - 07:46 AM

It happens occasionally, but the only way to notice it is to try to move or delete the file which is locked, so you won't notice it if you don't do that. The main problem is that I have no idea what's causing it. This is on Win XP SP3, LV 2009. I think it also happened with LV 7.0, but I'm not sure.


I'm on Win XP SP3 but don't have 2009 installed yet on my main machine which I use to work mostly. And I may not really use the applications where you see that. However I have frequently many applications open and also work regularly in Explorer to move files around, but if I had problems with files appearing locked they were either executables running (Windows allows renaming them though, so you can rename it and place a different executable under the old name although that could crash badly if the paging kicks in), directories locked by the SetCurrentDirectory() issue in the Common File Dialog or DLLs that are still opened in LabVIEW despite me having closed the VI that called them. Sigh!

#19 Yair

Yair

    Extwemely Active

  • Members
  • PipPipPipPipPipPip
  • 2,749 posts
  • Version:LabVIEW 2009
  • Since:2003

Posted 17 March 2010 - 05:23 PM

Rolf, I assume that if anyone would know, you would - the only file type I can remember this locking happening to with reasonable certainty is an .avi file. Is it possible that Explorer somehow sent the open command to LV as well because the extension had "vi" in it?

I'm assuming not, because my understand was that the extensions are explicitly recognized using CLSIDs, but it's a guess.

#20 rolfk

rolfk

    LabVIEW Aficionado

  • Premium Member
  • 2,320 posts
  • Location:Netherlands
  • Version:LabVIEW 2011
  • Since:1992

Posted 17 March 2010 - 06:47 PM

Rolf, I assume that if anyone would know, you would - the only file type I can remember this locking happening to with reasonable certainty is an .avi file. Is it possible that Explorer somehow sent the open command to LV as well because the extension had "vi" in it?

I'm assuming not, because my understand was that the extensions are explicitly recognized using CLSIDs, but it's a guess.


Well the CLSID isn't the primary mechanisme really to determine what application to open for a file type. It can come into play but the normal path is that the key in the registry matching the file extension is queried and that is usually an alias to another key that contains the actual information how to launch the according application. The primary key can also contain optional information such as the list of program IDs that can cope with that file and also CLSIDs for applications that should be used to handle the file but this last one is not the normal operation for most file types.

A agree that the avi and vi extension have some similarity but this would mean that explorer has gone bad when parsing the file extension AND that LabVIEW somehow holds on to filehandles for files it was not able to handle and simply refused them. Quite a combination of unlikely coincidences.