App keeps files locked when exe but not as development

[TeraTech]

I have a LV application that generates files, places them in a temporary folder structure during the test and at the end of the test moves the files and folders to another final destination.  When the application is run from development environment, I can open file browser and view the files with preview and/or open them.  When the application is run from a compiled exe, the files remain locked and cannot be previewed or opened and displays “The file is locked by another program”

Environment

LV 2017 17.0.1f3, Window 10 Pro 21H2

Summary

1. If I run the app in development mode, the produced files do not stay locked. If I run a compiled Exe the produced files stay locked.
2. The files remaining locked only happens when the application saves to a network location. The produced files do not remain locked if they are saved to the local C drive.
3. Simply exiting the exe does not unlock the files. The only way to unlock the files is to log out of my pc.
4. The issue is only with Window 10. The same exe run on Win 7 does not keep the files locked.
5. I have tried 2 different network locations, the first being a domain server’s drive and the second a PC drive on a private network.  In both cases the files remain locked.
6. I can reproduce this issue from 2 different computer logged in as 2 different users.

Code details:

1. The “move” operation is performed by calling the LV native Copy function followed by the LV native Delete function (with Delete Entire Hierarchy=True)
2. Neither the copy or the delete functions produce errors.

I thought it might be a disk caching issue, but I’m not sure why caching would be any different for development mode vs an executable. 

Hoping your collective brains can help! 

[Bob_Schor]

I tried to replicate your finding, with LabVIEW 2019 (32-bit) and Windows 10 20H2.  Our group has a Share that I've mapped to Y: and on which I have a folder.  I created a "Hello, World!" text file on the Share, closed it, waited 1 second, opened it, read it, closed it again, and stopped.  The output showed "Hello, World!", as it should.

I then built this as an Executable and ran it again.  It ran fine.  I was not able to replicate the failure you found with writing to your network.

Bob Schor 

[TeraTech]

Thanks @Bob_Schor. I replicated your little test in my LV 2017 environment and was able to verify your findings as well. The test exe was able to reopen the file. However, what if you browse to the file with file explorer? Are you able to preview and/or open the text file? Try it more than once. The first time I ran it, it allowed me to view it. Upon subsequent tries, the file became locked. What if you leave the exe running and try to view/open the file, is it locked? Does it become unlocked when you close the exe?

[Eric1977]

Can you show us (attach your VI) how your opening/closing the files? That would help us quite a bit.

I'm asking because there may be something upstream in your code that someone could identify and state that it could be the or a potential problem.

[TeraTech]

Hi Eric. I was able to reproduce the problem with Bob's snippet. (I had to retype it in because I don't have LV2019 installed) The key is to try to open or view the file with something other than the Exe that generated it.

[TeraTech]

It seems that using Notepad, the default app on most PCs for opening txt files, does not exhibit the.  Try opening the txt file using Excel. It gives me read only message.

Just as an aside, the problem is not specific to text files. My actual app creates and save screen snapshots (jpg), text files and html reports.  All of the file have the same locking issue. The only way I've found to unlock the files is to log out of the PC that generated them.

[StevenD]

If you have the file reference open, the file will be marked as locked. Are you sure you are releasing the reference? Are there any errors going into the close reference node?

[Bob_Schor]

Tera,

     I'm currently not at work, so don't immediately have access to the Share.  It occurs to me that if the file has been opened (and not closed) by LabVIEW, it should be "locked" to having another process open it.  I'll modify my simple code to let me separately open for writing, write some stuff, pause (so I can try to let File Explorer try to read it), close it, re-open, extend the file, etc.

What kind of files are you reading/writing?  I was doing a Text file, using Text Read/Write.  I could imagine reading/writing binary files, or Delimited Spreadsheets, might show differing behavior.  So before I put too much time and effort into this, why don't you tell us a bit more about the type of file I/O you are doing?  Can you write a small demo (similar to what I wrote) that fails, so we can test it, maybe with differing versions of LabVIEW, of Windows, etc.?

Bob Schor

[rolfk]

When specifically opening a file you can specify what share mode should be used, Default is “deny read + write”. When using directly a file Write node it will use the default. I NEVER use the wrote or read directly but always with an explicit open first and a close afterwards. 

That all said, Windows has a tendency to mess with file locks when the file location is on a network share, especially if it is not their own SMB. And even then things can get messy since SAMBA under Linux has sometimes their own ideas about how to implement certain requirements.

I have regularly locked files on my NAS that File Explorer claims are locked and mostly without any relation to LabVIEW and often restarting Windows is the only option to convince it that nobody has those files locked.

[TeraTech]

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.