AHK Permanently Locking Files After FileOpen() Topic is solved

[Exaskryz]

I'm probably missing something here. I've got a routine for writing a CSV file. I've been using something of this sort:

Code: Select all

csv:=FileOpen("My.csv",2)

I discovered that many hours of data was never written to the file. So I explored, and researched A_LastError. I found out a system error of 183 indicates the file exists, so AHK fails to create it, and is instead opening it to write it. This is normal behavior for AHK as far as I can tell when using Append mode. I found out the lockout error is Error 32. In the event other errors arose, I opted to check that A_LastError is not 183 instead of just checking for A_LastError=32. (As a bonus, I also wanted to detect when A_LastError is zero, as that meant it was a brand new file I was writing, and that I wanted to put a header to it.) If I get an error besides 183, I am writing to a brand new file.

Code: Select all

csv:=FileOpen("My.csv",2)
If A_LastError=0
   csv.Write("Headers`r`n")
else If A_LastError != 183
   csv:=FileOpen("Backup " A_DD A_Hour A_Min " .csv",2)

Then I would go onto the rest of my code with csv.Write().

Then I end it off with csv.Close().

I think this is a result of my computer managing to fall asleep; I haven't tested if the code can still run when sleeping, but I'm pretty sure on the occasions that I wake my computer up (I've set it to never sleep when plugged in) it starts to create these Backup files.

And it creates a series of them until I restart my computer to clear the lock on the main files.

I have researched using Resource Monitor (windows 8/8.1/10 native app apparently) to identify a locked file. But searching the names of these files gets me no results. Searching for a file opened in Excel, as a test, does find the file as locked by Excel. Which means either Resource Monitor is faulty and can't find AHK processes hiding in memory, or something has happened and when AHK's process terminated it did not release the files.

What can I do to ensure AHK releases the lock on the files?

[just me]

Sharing mode flags:

If Flags is numeric, the absence of sharing mode flags causes the file to be locked.

[Exaskryz]

Oh yes, I read that and reached a totally different conclusion last night. I somehow decided that trying to use 0 in flags would work, but maybe it would...

So I should be using FileOpen("My.csv","a") instead of FileOpen("My.csv",2)? Or should I be fitting in the 0x200 or "-w" in there somewhere, so, FileOpen("My.csv","a-w") (or "2-w"?

I'll try them all out at some point here for experimenting. But I tested the first option, "a" on the main fail instead of a backup or test file on accident, but it seemed to work, even though it might have had a lock on it. So maybe my initial diagnosis was wrong and there is some other error happening that isn't locking the file; changed up my script to record the A_LastError inside the Backup file.

[just me]

I never used numeric flags. I think ist should be

Code: Select all

; either
FileOpen("My.csv", "a")
; or
FileOpen("My.csv", 0x0702)

That's all AHK can do to offer shared access.

[Delta Pythagorean]

Instance.Close()

[Exaskryz]

Is Instance a special object in AHK? I have used .Close() from the getgo.

Just tried changing my 2s to "a"s, will see if it affects anything.

Edit: Seems using "a" is better than 2. I never restarted my computer to release the hypothetical lock, but the file is now written to by changing my script to use the flag parameter "a". Maybe I was wrong about a lock existing on the file (supported by the fact that Resource Manager wasn't finding a lock on a file), and that it was some other error thrown by AHK trying to put a lock onto it...