Errno 13 Permission denied when editing game exe.

[massimilianodelliubaldini]

Needs more research. Problem is intermittent and not readily reproduced. Install location of the game has been ruled out, as well as running the script/python itself with admin privileges.

[massimilianodelliubaldini]

Could an untimely Windows indexing service be causing this issue?

Dealing with such an issue elsewhere and it jogged my memory that this could be similar.

[WinkelCode]

In that case it might be worth it to make it so that if the script detects Error 13 it waits maybe 3 or 5 seconds and then tries again until it succeeds or the user cancels it.

[massimilianodelliubaldini]

Do you know if the error happens when the file is:

1. copied to a backup
2. first read and stored into a variable
3. re-written with new data
4. read again and verified against a backup?

[WinkelCode]

I know that the one time where it happened under "normal" conditions on the "real" PC from which I play AC7 it managed to create the backup so I guess it must've been Step 3. ? (Since the backup was created I am guessing reading wasn't a problem)

I also had a test environment where not even the backup would create but the more I think about it that was probably due to some permissions weirdness due to transferring a file via an NTFS volume between machines, it was the same error but most likely different (and not really relevant to normal users) cause.

Edit: There is also the possibility that the error happened while it was creating the backup, maybe it can't handle getting interrupted by Windows Defender in some situations? It's something to keep in mind but I think it's pretty unlikely, especially considering the clear "permissions denied" error.

[massimilianodelliubaldini]

Good to know. I'm trying to think if I want to wrap each of those 4 steps in their own try/catches, or wrap them all under 1 big try/catch. If you succeed at 1 and 2, but fail at 3, do you want to retry 3 only, or go back and do 1 and 2 again? I'm leaning on the former.

[massimilianodelliubaldini]

Will leave this issue open because that PR provides no positive proof for a fix. And maybe someone will comment that they can still duplicate the problem even on the newest update.

[1992Andrew]

Hey, I'm having... sort of the same issue. Its the same OSError 13 but the actual problem seems to be that the thing isnt actually doing its "wait 5 seconds and try again" thing. Its moving so fast that it seems likes its waiting 5 milliseconds and then trying again and it does it 5 times, copying the output I am getting below at the very end. Ultimately what this is resulting in is that it does everything correctly **except for fixing the hud. Well, that and it doesnt unpack migoto. This only started after I updated to the latest windows build, 1909. Before that, everything was fine. Any ideas for what I can try to get this working? Again, in-game literally the only thing wrong is that the hud is still offset to the left of center. Even with this error-ing out it seems to do almost everything right.

WARNING: This mod may be flagged as a cheating tool by the new Ace Combat 7 anti-cheat system going live in August 2019.
This developer holds no responsibility if this mod results in an online ban.
Are you sure you wish to continue? Y to continue, N to cancel:Y
Your screen size appears to be 3440x1440.
Is that correct? Y to continue, N to cancel:Y
Determining FOV hex value...
Horizontal FOV: 106.7 degrees.
New FOV hex value: D0 F9 2F 3C D8 F5
Backing up the game exe...
Modifying the game exe...
Verifying the game exe...
OSError 13. File may be locked by another process.
Will wait 5 seconds and try again. Attempts remaining: 5.
OSError 13. File may be locked by another process.
Will wait 5 seconds and try again. Attempts remaining: 4.
OSError 13. File may be locked by another process.
Will wait 5 seconds and try again. Attempts remaining: 3.
OSError 13. File may be locked by another process.
Will wait 5 seconds and try again. Attempts remaining: 2.
OSError 13. File may be locked by another process.
Will wait 5 seconds and try again. Attempts remaining: 1.
OSError 13. File may be locked by another process.
ERROR: Unable to verify game exe. Press any key to close.

[massimilianodelliubaldini]

@1992Andrew Thanks for throwing in the output. Not being able to duplicate the issue is proving challenging because I can't really test a fix for it. Hence I forgot to add the time.sleep(5) calls and didn't catch it on review. Latest push to master should fix that.

That's not to say that that idea would fix this problem at all. If you are still running into this issue, try 2 things:

1. Exit and close Steam and any other background processes that relate to games (Steam, GOG, Origin, Epic, etc), then try running the script.
2. Disable those games processes from Startup, then shutdown and restart your computer, then try running the script.

I should have thought of them as potential suspects long ago, but its still only a guess.

[1992Andrew]

Good ideas for shutting down those programs that might be touching the game's exe but those were all things I tried myself before commenting; sadly it didnt work.

However! You fixed it with your latest edit to the python file! :) It still hit the error one time but once it retried, it pushed through to completion. Thanks for such a quick response!

If i may provide my thoughts on the issue: since this is what seemed to do the trick (and all the many other things i tried not having any effect)... I actually think that its your script itself that "has the file locked" and it just doesn't realize that its itself that is actually the culprit. Almost as if that its trying to verify the game file too quickly after backing it up, thus whats "got it locked" is that the script wasn't quite finished backing it up before beginning the verification process.

I'm not too sure how viable that explanation is; I know it doesn't make much sense from a coding perspective and you'd think that more people would be having the problem if this explanation was in fact correct but its a thought that occurred to me yesterday given how fast it was blitzing through the 5 re-attempts so I thought I'd mention it. And it seems to me to be reinforced given how nothing else fixed it except the insertion of code specifically meant to cause it to stop and take a breath before continuing (if I may use an analogy).

Perhaps its a matter of how fast a user's individual computer is running the file, I have my Ace Combat 7 on a very fast SSD, to which python is also installed on so maybe its that my own device is running your script too fast.

Regardless, its working for me now, and I can play again. Thank you so much.

[massimilianodelliubaldini]

Thanks for your detailed analysis! I'm intrigued that it failed once but worked on a subsequent attempt after 5 seconds. So if the script is creating a race condition on accessing the file, I'm going to look into the Python documentation for things to that effect.

Personally I have the OS and Python installed on an SSD, but the game on an HDD. But if different hardware configurations were an issue, we'd still be talking about a race condition - it should work on all hardware setups, so that's the angle I'm working right now.

My only problem is that race conditions require another thread, but there's no multithreading in the script, and I don't think the file access calls I make spawn another thread as part of their implementation...

Thanks again for your feedback!

[Hacksaw49]

Just had the same issue with the script running it on my M.2 NVMe SSD. I copied over the required files to my HDD and it ran fine. Copied the files back into the game folder and the mod worked. Thanks!