First post, by jarreboum
Hi,
Well it's more of a suggestion, I'd like to know what you think about it and if it's feasible in the future. Everything is written from a Linux point of view, but I suppose it could also be applied to other OSes.
I'm interested in protecting my static data from user error / OS error / corruption as much as I can. As such I tend to mount some of my directories as read-only to keep mistakes from happening. For example my /usr/local/share/games is mounted remotely and as read-only. It contains OS-independant static game data, such as Doom wads, MAME roms, openXcom original DOS files, ScummVM games. Access to the data is a tad slower than if it were on a local drive, but I honestly don't feel much of a difference on a daily use. It also makes setting up a new computer really easy. I wish I were able to do the same with my DOSBox games.
Unfortunately DOS games have to make modifications to their own folder. They either modify existing settings files, or create new files containing game saves on a per user basis. This behaviour is inherently incompatible with the idea of read-only static data. What I currently do is that I locate the files containing the game saves, move them to a local writeable directory (somewhere in $HOME) and make a symlink back into the DOSBox folder. This is unsatisfactory for three reasons. One, it's a very lengthy process that can only be automated to a point (new games need new research), two I need to temporarily grant write access to my files, and three some games are just impervious to the process, creating new files as the user makes new saves.
What I wish to see is a new line in dosbox.conf, allowing to redirect every change to a shadowed directory in the user space. This is how it would look:
- "/usr/local/share/games/dosbox/sim city 2000" is read-only, and mounted as C: in DOSBox.
- The game saves scenarios as C:\SC2000\[name].SC2 .
- When writing is detected, the new file "$HOME/.dosbox/sim city 2000/SC2000/[name].SC2" is created.
- From within DOSBox, both paths are virtually merged, showing as one.
- If there is a file name conflict, files in user space take precedence.
I don't think it's a very innovative concept, but in the case of DOSBox it would help a lot in keeping static data and user data safely separated, so they can be saved and retrieved in their own right. It's also very beneficial to a multi-user environment.
One caveat would be that there would be unexpected files appearing when mounting different directories with the same name. Then again I expect the user keeping two [game] folders is doing it for test purposes and knows what he's doing. In fact it would help his tests to just copy the folder with a different name and get a brand new install ready to welcome tweaks. Users keeping a global /dosgames with everything installed within wouldn't be affected either (they wouldn't want it read-only by default anyway, in order to be able to install new games.)
Sorry I'm verbose. But what do you think of it?