VOGONS


First post, by jarreboum

User metadata
Rank Member
Rank
Member

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?

Reply 1 of 6, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I think they invented unionfs for that matter on Linux.
Have fun with it.

Water flows down the stream
How to ask questions the smart way!

Reply 2 of 6, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

There's also the physfs patch that does the same kind of thing with ZIP files instead of folders. I think the Daum build may have incorporated it, but not sure about current status.

Reply 3 of 6, by jarreboum

User metadata
Rank Member
Rank
Member

Physfs support is exactly what I was describing, that's cool! You can apparently use two folders, the first one being the writeable one.

I'm not familiar with the process of forks and SVN, what are the chances of having these patches included in mainline DOSBox 0.75?

Reply 4 of 6, by kolano

User metadata
Rank Oldbie
Rank
Oldbie
jarreboum wrote:

Physfs support is exactly what I was describing, that's cool! You can apparently use two folders, the first one being the writeable one.

I'm not familiar with the process of forks and SVN, what are the chances of having these patches included in mainline DOSBox 0.75?

I'm not sure, but probably not very good anytime soon. You can grab a pre-compiled version that includes it (i.e. DAUM build) here: http://ykhwong.x-y.net/.

Eyecandy: Turn your computer into an expensive lava lamp.

Reply 5 of 6, by jarreboum

User metadata
Rank Member
Rank
Member

Yes, I got it from there, thank you.

I was not really asking about when it would be included (I know such question is taboo), but merely if such fancy patch could ever be included in the main version, whenever it's out. What's the general policy on accepting patches? I see it was worked upon since 2005, presumably not quite ready for 0.74. Now it seems quite stable (from my 5 minutes testing, eh), so is it considered for inclusion in the next version? Or does it fall outside of the scope of DOSBox and should stay in the realm of forks?

Reply 6 of 6, by idspispopd

User metadata
Rank Oldbie
Rank
Oldbie

In pure DOS I used the APPEND command for a similar purpose. (In that case, playing 3-disk Sierra games without swapping floppies, using one floppy in both 360k drives and one 360k RAM disk.)
Did you try this? According to APPEND? that should work.