It should be possible to automatically use dosbox support for VFS on readonly mediums

[i30817]

Imagine that you're starting a .conf file from a dvd (or more to the point, from a mounted read only lz4 filesystem) - it should be possible to check that directory is read only and do something about it by assuming a conf file is always at the top of the game 'dirs' (warning, this is not always true for badly made installs, though not GoG installs because dosbox doesn't have support for platform independent host directory separators in conf files).

edit: this is probably going to happen in upstream in the 'next' release, but will probably have to be adapted to libretro at least, and may not occur automatically which is the part that would be handy imo. It may also happen for zipped games.

I already have something that does this, but it requires a fixed source filesystem (i didn't bother to handle multiple possible filesystem mounts) and doesn't treat individual games as 'individual'. I suggest to use as 'filesystem cache id' the name of the parent dir of the conf file (or exec if not) as the 'id' of the game, possibly postfixed with a hash of the conf or executable (maybe not that last, because some executables self modify to 'save' for instance). Some games are weird and place their actual .exe files in subdirs, but i'm assuming that in those cases there will be a bat or conf file above you actually want to use anyway.

[i30817]

Oh btw, from the GOG fork, it appears that these commands are done on mount of the config files, so it's 'possible' you might want to not do anything 'special' for this and place it all on the users to edit the conf files, but it would be unfortunate if the copy on write only worked for 'native' host filesystems and not dosbox support for hdd images, specifically win95/win98 boot and secondary images, so consider that a additional request if this doesn't work for that. My scripts linked above can work on that situation because they create a copy-on-write filesystem below dosbox itself and in that situation, copy the whole hdd.

[realnc]

Does the "enable overlay" core option already basically do things correctly? If yes, then I could add a new choice for that option called "auto" or similar that enables the overlay if the content directory is read-only.

I don't think it's necessary to add any checksum verification, because you can't have two files in the same directory with the same name. So if you have two .conf files named dosbox.conf for example, they have to be in different directories and so will get different directories inside the overlay.

[i30817]

Does the "enable overlay" core option

Didn't realize this already existed here? It does?

I don't think it's necessary to add any checksum verification...

but you can have same named parent directories for the conf. Remember the folder structure doesn't have to be 'simple'. It's perfectly viable for a two different games to have the same named parent dir if they share a engine and the executable is placed in a subdir, or for instance you make two copies of the game and configure one differently (lets ignore for now the troubling fact they could have the same named exe, so it's possible even the conf has the same name and crc since that is even more unlikely, defense in depth of a kind).

A interesting (better) alternative I just thought of is if a hash of the whole absolute parent path was part of the key. That would lock the cache to that particular location and if you moved the game it would have to have a new cache, but it might be worthwhile for certain uniqueness on the filesystem (unless the two executables are in the actual same dir, like a expansion, for instance syndicate and american revolt but in that case it doesn't matter if they use the same cache dir).

A hash is not necessary for this scheme, but i thought it would be more user friendly than a huge folder structure replicating the absolute path in the cache path, but if you do that instead you get stateless idempotency where you don't have to 'remember' the target of the cache directory at any time in dosbox state to operate on the cache (Linux does something similar with the .local dir being able to replicate and override any absolute path and wine does the same to 'remember' what the windows path is supposed to be). That makes it hard to delete individual game caches as a user though since the toplevel cache dir would just be 'C:' or 'home' for all games and idempotency is probably unnecessary for dosbox.

[i30817]

I realized that unfortunately this will not work for imgmount'ed images yet, which are used for windows 95 and copy protected floppies. As the dosbox 'dos' doesn't manage the files inside them but windows, there is no file handles to hook into, unless there is a special kind of copy on write 'just' for image files (upstream might do this eventually).

I currently use a external fuse filesystem stack with a squash mount with a copy on write mount on top for this and it works on both cases (unfortunately copying the whole image with copy on write the first time in the case of image files, which can be a bit brutal, but does support windows 95).

[i30817]

I was wrong about GoG installs not possibly screwing up dosbox.conf locations btw. They do require the paths to be 'portable' but '..' is shared between unix/windows and doesn't use the path separator so i can easily see a gog conf doing 'mount c ..' and the game expecting to write on '..'

I think this is just one of those things that will have to be taken on faith and warned about on the feature readme.