Rpcs3: RPCS3 complains about another instance running when placed in a folder requiring administrator privileges

[B-Knight49]

Quick summary

Placing RPCS3 in a folder that requires elevated permissions (like Program Files (x86), for example) opens a fatal error messaging claiming that another instance is running and it must be closed.

Details

• Intel Core i9-9900K @5.00Ghz
• GTX 980Ti 6GB
• 16GB DDR4 TridentX RAM
• Windows 1909 | 18363.657

[vsub]

The question is why will you place a portable program that can run from anywhere in a place where portable programs usually have programs running from unless they are granted admin privileges.

Check if rpcs3 is in your task manager(More Details)before trying to run it.

PS.You will not gain much of a loading speed boost even if your games are on your SSD(you will get some speed boost only the first time you load a new game after windows restart)
I have tried placing games in a ram drive and there is not much difference the second time I run the same game

[B-Knight49]

I've had RPCS3 there since 0.0.3 or lower. Just never moved it. And no, it's not open. Running with admin privileges makes it open instantly.

Also, all my games are not on the SSD. They're symlinked to my HDD. The SSD is used to (from what I personally can tell) faster loading of shaders and files from disk.

Moving it isn't really a solution to this either. It shouldn't be saying what it's saying. A hacky workaround is hardly the correct response to that.

[AniLeo]

You're not supposed to be running RPCS3 with admin privileges at all. I guess it can detect if it's on Program Files and error out with a message asking for it to be moved.

[CookiePLMonster]

Just edit rpcs3's folder security settings so it's writable by everyone. That's what Steam does and everybody is happy.

[Nekotekina]

(x86) lol.

[B-Knight49]

I think you guys are missing the point - I can easily just move the program elsewhere, edit the folder or edit the compatibility to just run as Admin always. The point is, it shouldn't be saying "another instance is running", it should be saying "don't run it from somewhere like Program Files (x86) or another folder requiring elevated privileges".

Also, what's "lol" about x86? It doesn't make a difference where it is, RPCS3 will function identically all-the-same, regardless of folder. I obviously don't have a 32bit system...

[kattjevfel]

Also, what's "lol" about x86? It doesn't make a difference where it is, RPCS3 will function identically all-the-same, regardless of folder. I obviously don't have a 32bit system...

RPCS3 is not a 32-bit application and should not be in the x86 folder, I mean I'd argue it shouldn't be in those folders at all, but that's already been said.

[CookiePLMonster]

The point is, it shouldn't be saying "another instance is running", it should be saying "don't run it from somewhere like Program Files (x86) or another folder requiring elevated privileges".

I'm not totally convinced you can differentiate those two cases. Both throw "access denied" on the file and I'm not sure if you can get more detailed information than that.

[B-Knight49]

RPCS3 is not a 32-bit application and should not be in the x86 folder, I mean I'd argue it shouldn't be in those folders at all, but that's already been said.

The folder makes no difference. It's a name. Putting a 64bit application in Program Files (x86) or a 32bit application in Program Files will change absolutely nothing. There is absolutely no fundamental difference between them other than their name. It's just something traditional and become de facto - kinda like why I've not moved RPCS3, nothing more than simple laziness and because I've come to expect it to be in that folder.

Also, you do realise that Steam installs everything to Program Files (x86)? That's including all games along with obviously the application itself. Is Steam a "lol" because it installs there instead of Program Files or anywhere else? 90% of all the games are 64bit... Didn't think I'd have to be defending myself over what folder name RPCS3 is located in.

I'm not totally convinced you can differentiate those two cases. Both throw "access denied" on the file and I'm not sure if you can get more detailed information than that.

Fair enough. Obviously this is a low-priority issue and is literally just a visual bug, so no rush. Close it if 'won't-fix' or just not worth the extra effort. And thanks for actually discussing the issue lol.

[bevanweiss]

@B-Knight49 can you please re-test?
When I looked at the code for this just before it looks like there is a handy-dandy error message alerting the user to exactly what the problem is now.
With the way that the single-instance handling is done (using a lock file), this is the best we can do.
There might be some valid questions around why we have single instance... but that's a different question/issue.