Naturally, some changes by the GUI may have a bad effect on a potentially running game. At least two are rather problematic, since they might produce invalid states:
Upgrading the backend.
Deleting the UCP.
If the game is running, certain files are locked, so both of these actions could not only crash or break the game (something other actions could also), but easily produce an invalid folder state.
To avoid these, two actions should be performed:
The warnings/messages for these actions should explicitly include a mention of the possibilty of invalid state should the game be running or any file be opened.
A simple check should be performed if any of the games are running. To avoid adding other dependencies by now and still be rather compatible, the binkw32.dll should be renamed or moved and back. An error due to file locks on Windows should indicate that the game is running. On Linux, this would depend on Wine, but in case the locks are not emulated, than they will also not cause issues. Note: The method to check should NOT suggest by name or otherwise that it is a proper game running check, to avoid misconceptions. Something like testForFileLockOnBinkw() would be better.
Thoughts:
In theory, no folder altering action should run if the game of the current folder is running. The issue is that checking this on every action would be impossible, even if a proper check exists. The GUI would need to be locked, except the action to change the folder. The process creation could actually be modified to keep a stream to the game open, which would indicate that is running. However, this would only work with games started from the GUI, so it would not be reliable. This handling is likely overkill for now, so the easier fix should be tried.
Naturally, some changes by the GUI may have a bad effect on a potentially running game. At least two are rather problematic, since they might produce invalid states:
If the game is running, certain files are locked, so both of these actions could not only crash or break the game (something other actions could also), but easily produce an invalid folder state.
To avoid these, two actions should be performed:
binkw32.dll
should be renamed or moved and back. An error due to file locks on Windows should indicate that the game is running. On Linux, this would depend on Wine, but in case the locks are not emulated, than they will also not cause issues.Note: The method to check should NOT suggest by name or otherwise that it is a proper game running check, to avoid misconceptions. Something like
testForFileLockOnBinkw()
would be better.Thoughts: In theory, no folder altering action should run if the game of the current folder is running. The issue is that checking this on every action would be impossible, even if a proper check exists. The GUI would need to be locked, except the action to change the folder. The process creation could actually be modified to keep a stream to the game open, which would indicate that is running. However, this would only work with games started from the GUI, so it would not be reliable. This handling is likely overkill for now, so the easier fix should be tried.