App keeps files locked when exe but not as development

[Bob_Schor]

Three comments:

1. Your "Read" value-change Event has no File Path wired.  Recommend you place File Path outside the While Loop to guarantee same path used for Read and Write.
2. You shouldn't need a Quit LabVIEW call (or at least I don't understand why you need it).
3. You provided a VI without a Project.  How did you build your Executable?  [The only way I know how to do this is with a Project File, which is usually inside a Project Folder].  It might be helpful if you included the Project File -- maybe you have some "unusual setting" (or I'm forgetting to set some "important" setting).

I think I might be able to get to my Share and try your code (with Fix #1, above, and possibly without the Quit LabVIEW, Fix #2).  But first, I need to create a Project File and build that executable ...

Bob Schor

[Bob_Schor]

---

I think I might be able to get to my Share and try your code (with Fix #1, above, and possibly without the Quit LabVIEW, Fix #2).  But first, I need to create a Project File and build that executable ...

---

OK.  I meant what I said, and I said what I meant (from "Bob Hears a Who").  I took your code, made sure the file path was outside the While Loop so both Read and Write used it, wired a "False" constant to the "Quit LabVIEW", put my revised VI in a Project (called Test File Locking) with no special options (but I did save the VI with the file path to my Share as the default value, lest I forget).  Here are the steps of my trial:

1. Run Executable, press "Read".  I expect to see "Hello, World!" (as I'd read it from the Share earlier), and I did.  I then used File Explorer to find Test.txt on the Share and dragged it to an open copy of Excel's "Open" icon, and a WorkSheet popped up with "Hello, World!".
2. I then changed the "write text" to "Hello again, world!" and pushed "Write".  Again, went to Excel, opened the file on the Share, and read "Hello again, World!".
3. I did another "Read", and (as expected) saw "Hello again, world!" in "text read".

I have no good idea why this doesn't work for you.  [I actually wrote the previous sentence as "... why it works for me, but doesn't work for you", but then I said to myself, "Of course this works for me -- this is how it is supposed to work.  Surely in over 30 years of use, LabVIEW wouldn't have problems with I/O to Shares breaking when users create executables without finding and fixing this ...].

One thing I realize I didn't test was having the Quit LabVIEW function "live" and actually using it.  I don't think this should mess things up, but I don't know.

It seems to me that the problem is more likely to be "on your end" (and I don't mean to be criticizing you, but maybe a glitch in your LabVIEW system, your network or security settings, or maybe in your PC).  Can you take your test routine, "fix" it as I did, build and "Excel" test it as I did, and verify that it is still failing for you?  Maybe someone else on the Forum can chime in, either by replicating your test or suggesting something to try that neither of us has thought about ...

Bob Schor

[billko]

---

@TeraTech wrote:

I was able to reproduce the issue with the snippet provided by Bob_Schor which uses text file, which clearly closes the text file. Agree that writing other types of files and using other file write methods may introduce different behavior. Since we are able to reproduce the issue with text file, shouldn’t we stick with that to keep it simple for the time being? 

I created a small Test File Locking app/exe that others can use for testing. If there is a need, I can produce an example that writes and read other file types.

Regarding the attached example, you must compile it to an exe to witness the file locking.

The only thing you need to remember is that with a text file, you can open it in notepad even when it’s locked so you can’t use that as a test. To witness the file locking you can open the file explorer preview window or try to open the text file in something other than Notepad, that you know will warn you of a file like – in my case I use Excel.

---

Maybe now we are getting somewhere.  You mention "this thing" only happens with the executable, but not in dev mode.  Then you show some code that "does something different" as an executable than it does in dev mode.  Maybe explore that difference?  (i.e., disable the case statement with the "Quit LabVIEW" vi.)

Note that "Quit LabVIEW" stops your code exactly like using the abort button.  Maybe this leaves references open?  In my experience, LabVIEW HATES to give up file references, and shutting down LabVIEW in a graceful way is sometimes the only way to get LabVIEW to release its grip on a file.  Maybe aborting an executable like that doesn't give LabVIEW a chance to finally give up its reference (even though you already told it to close the reference)?

I know somewhere buried deep in ancient LabVIEW lore, there was a recommendation to use "Quit LabVIEW" when exiting an executable, but I think those days are long gone.  You can just let it close gracefully now.

[rolfk]

I took your VI, created a project and built the executable, then run it. I can create a file on the local disk as well as my Synology NAS and then select it in explorer, independent if I quit the application or not. The preview pane simply shows the text.

LabVIEW 2018 SP1, 32-bit, Windows 10, 64-bit, version 21H2.

[TeraTech]

@Bob_Schor: I didn’t attach a file path to the file open because I wanted it to throw up the dialog, for flexibility. That way I can peak at previously written files to see if their locks had been removed. Point taken. : )

---

@billko wrote:

---

---

Maybe now we are getting somewhere.  You mention "this thing" only happens with the executable, but not in dev mode.  Then you show some code that "does something different" as an executable than it does in dev mode.  Maybe explore that difference?  (i.e., disable the case statement with the "Quit LabVIEW" vi.)

Note that "Quit LabVIEW" stops your code exactly like using the abort button.  Maybe this leaves references open?  In my experience, LabVIEW HATES to give up file references, and shutting down LabVIEW in a graceful way is sometimes the only way to get LabVIEW to release its grip on a file.  Maybe aborting an executable like that doesn't give LabVIEW a chance to finally give up its reference (even though you already told it to close the reference)?

---

I will explore the difference between dev and Exe further and look into references that may not be releasing.

Keep in mind, from my original post:

• 4. The issue is only with Window 10. The same exe run on Win 7 does not keep the files locked.
• 6. I can reproduce this issue from 2 different computer logged in as 2 different users.

I will refine my test app, do further testing and repost. 

[TeraTech]

Removed the Quit function. Still leaves the file lock after exiting. Couldn't find any project setting that would impact the file locking. In the meantime, posting my slightly tweaked Test File Locking project.