If you use the SVN of dosbox, then the -t overlay system would more or less provide this functionality. (it allows you to mount 2 directories on top of each other, where the overlay one gets the new/changed files)

Kahenraz wrote:

Files stored under /usr/share/ are not writable by normal users.

Then don't put your DOS game files in there. Mount some writable path as the C-drive in DOSBox.

Why don't you just place SAVE inside drive_c and give your user write permissions only to the SAVE folder?

Something like:

chown username /usr/share/games/<game>/drive_c/SAVE

zirkoni wrote:

Kahenraz wrote:

Files stored under /usr/share/ are not writable by normal users.

Then don't put your DOS game files in there. Mount some writable path as the C-drive in DOSBox.

pantercat wrote:

Why don't you just place SAVE inside drive_c and give your user write permissions only to the SAVE folder?

Something like:

chown username /usr/share/games/<game>/drive_c/SAVE

I'm packaging these games in an RPM for a private repository and I'm following the Filesystem Hierarchy Standard (FHS). The contents of /usr are for read-only data. This is fine as most of the files for each game are in fact read-only. Save games are personal files and should be privately held in each user's home directory. This also alleviates problems where there is only a single "continue", limited save states, users deleting other people's saves, etc.

I'm setting up this repository for my nieces and nephew so that I can easily push games to them through a repository that will be available on laptops I'm setting up for them. This means simpler integration, easier deployment, and less maintenance on my part as I only have to package the RPM and it will "just work" on whatever system downloads it. This is also an exercise for me to learn how to package RPMs and deploy a repository. So I'm looking to do this the right way by honoring FHS conventions, even if it would be easier to simply 777 my problems away.

I like the idea of the new overlay feature. I'll look at the latest SVN and see if that will work better for my needs.

It is not a good idea what you are trying.

It certainly can be done. Create the appropriate group (dosbox). Create a directory in which users from the dosbox group will have write access (/var/dosbox/games).
Use mount -o bind,ro /var/dosbox/games /var/dosbox/games-ro
Finally, use the overlay file system.
https://blog.programster.org/overlayfs

edit:
Old dos games are no part of the Linux system (they are foreign). They should not be installed with the help of the system package manager. Skipping licensing issues is a separate topic.

You can see fuse based bindfs. Maybe it will do something.
https://bindfs.org/docs/bindfs.1.html

latalante wrote:

Old dos games are no part of the Linux system (they are foreign). They should not be installed with the help of the system package manager.

I'm making these games into simple, self-contained packages for this exact reason. Setting them up, especially on Linux, can be a pain and I only want to do it once. By wrapping everything up in a neat little package then I can easily both install and uninstall these games as I please.

For example, I've got a game here all packaged up that can be easily maintained through the package manager. It doesn't clutter up my home directory with game assets and even adds an entry to the applications menu with the game icon.

When I want to play an old game, I don't want to have to go through the trouble of digging up my disk images or ISOs, reading over docs, googling for patches and fixes, etc, etc, and then get the darn thing running maybe days later. I want to play it on an impulse for some nostalgia and then put it away. I'm an adult now and I've got things to do.

The ideal situation, and the reason I want to map files in this way, is to link save games to my home directory. That way I can install and uninstall and so on while preserving any games that I may have played. This is even more convenient than running on Windows as I don't have to fish around to backup save games or figure out how to restore them later.

I've opted to continue using the downstream version available in my distribution (0.74-3) for the time being and have all writable files linking to /var/games/<game>/. Notice how this decouples save games from the user and means that I have to remember to back them up if I plan on wiping the drive.