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.  

[TeraTech]

UPDATE:

The file locking problem continues but there was some progress. I have tested writing to a network drive from multiple computers.  The summary is:

• None of the windows 7 PCs exhibit the file locking issue.  
• All of the Windows 10 PCs do exhibit the file locking issue. (Win 10 (21H2 build 19044.2486)
• All of the above PCs are on our company domain. (Tried logging in as different users as well.)
• I compiled the Exe on a different computer, also with LV2017 (17.0.1f3), same file locking issue.
• I compiled the Exe on a different computer, with LV 2020 (didn't write down the SP version), same file locking issue.

However, I did discover:

If tested from a PC that is not on the domain, (i.e. Workgroup) then files produced with the "Test File Locking.exe" (from previously attached project) do not exhibit the file locking issue when writing the text file to a network shared drive. (Domain credentials were used to access the share i.e. DomainName\UserName and the PC had the same Win 10 build)

Progress!  Since the same Win 10 version and build was installed on the domain PCs and the non-Domain PCs, this points to something specific to our domain PCs such as security policies etc. Unfortunately, my IT guy is at a loss as to the possible cause. We already tried disabling/removing security software. The investigation continues...

[TeraTech · Accepted solution]

UPDATE:

It appears as though this issue may have resolved itself. I've received reports from users that the files are no longer remaining locked. Neither I nor my IT group have made any explicit changes.  My can only guess that recent antivirus update may have fixed it.

Just FYI: we had found a workaround, though we had not yet implemented it across all end user systems.   On the PC with the LabVIEW Exe, if you ran the Exe directly or a desktop shortcut pointing to the C: location of the app, then it would exhibit the file locking problem, i.e. leave the files locked. However, we mapped a network drive letter back to the C: drive. We then created a shortcut, using the mapped drive letter, to the LV exe.  When you use the shortcut with the mapped drive letter to launch the app, the app would not leave the files locked!  We are not sure why that worked, but as mentioned, we never needed to "deploy" that workaround, but wanted to post it here in case someone ran across this issue as well.

Thanks to all who help verify this on their systems!