mtasa-blue
mtasa-blue copied to clipboard
multitheftauto
Add solution to "permission denied" error message
Describe the bug Randomly, the MTA client is unable to join servers due to:
HTTP server file mismatch! (resource) fileName [CRC could not open file: Permission denied]
The solution is to restart MTA.
To reproduce Unknown as quite rare / random.
Expected behaviour Since fixing the bug may be too difficult (I've heard that the web server system is really old and too difficult to update) a good quick fix is to simply add something like "Restarting MTA may fix this" to the "CRC could not open file: Permission denied" error message. Players will think that the server they're trying to join is causing the error when it's actually a client side issue so would avoid time wasted reporting and investigating.
Screenshots
Version Multi Theft Auto v1.5.9-release-21129
Additional context
Yep. A button to restart MTA to attempt to fix the issue should do the trick.
Even restarting the MTA is not enough, sometimes the user really needs to open the game as an administrator.
Even restarting the MTA is not enough, sometimes the user really needs to open the game as an administrator.
Shouldn't MTA force the user to open the game always as administrator? 🤨
Shouldn't MTA force the user to open the game always as administrator? :raised_eyebrow:
I don't think it should. Windows introduced UAC because it is a bad security practice to run processes as administrator when they don't really need that many privileges. Moreover, requiring administrator rights renders MTA unusable by non-administrator users, which is troublesome for computers that have several user accounts or are not controlled by the player.
In my view, the best course of action for MTA is to fix the underlying problem, or at most tweak the error message to point out that a restart may help, but launching it as an administrator should be a no-go.
I agree, we should try to fix the issue.
I've actually just managed to replicate this error, by;
- having a server configured to use an external HTTP server (nginx)
- starting a resource which requires files to be downloaded
- watching the HTTP connections fail and it revert to internal HTTP server for each request
- restarting the resource while the download requests are still being made / failing / reverting to internal HTTP
This causes the CRC could not open file message on some files which previously had requests, whose operations were likely interrupted improperly/prematurely. It's clearly not freeing the file handle correctly that's still attached to our process (so there is still a lock on those files), just needs actually investigating/debugging.
Note: no idea if having an external HTTP server is required to reproduce, it may just be enough to restart a resource that's in the middle of downloading "normally" through internal HTTP. It's just how my local is setup (to use nginx - which I'd forgotten to run before launching my server).
