You are not logged in.

#1 2020-01-03 18:09:32

cubethethird
Member
Registered: 2016-01-25
Posts: 61
Website

How to treat global files as user local files

I'm working on a package for a game. The default behaviour for this application is to write game saves and such in the same directory as the application itself. I'm looking for a way to allow these to be bound to the user, storing them in e.g. ~/.local, allowing each user to have their own copies of save files. At present, the potential ways I've found this to be accomplished include:

- using synlinks (these would have to be created/updated whenever the application is run. Would also not allow multiple users to run it at the same time)
- using an overlayFS (has similar limitations as symlinks)

Unfortunately, it doesn't seem possible to have the application run with a different working directory, as there are assets which get loaded at runtime. To my knowledge, the application also does not offer a configuration parameter to select the storage location. I do not own or maintain the application directly, though I could try sending a request to add this as functionality.

What I want to know is if there is a best practice in terms of how this could be accomplished, or if there are alternatives I have not considered.

Offline

#2 2020-01-03 18:22:47

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: How to treat global files as user local files

What is the game?  Is it proprietary / closed-source as it sounds?

How big are the resources in the directory with the program?  Might it be feasable to just have something like the following in /bin/

#!/bin/sh

[ ! -d "${HOME}/.local/share/APPNAME" ] && cp -a /opt/APPNAME "${HOME}/.local/share/"

exec "${HOME}/.local/share/APPNAME/BINARY"

Of course, replace APPNAME, the /opt/APPNAME path, and BINARY with whatever they actually are.

But I find it odd that the program would actually save in it's own directory unless it is a script (and a script could be editted).  So that goes back to the first question: what game is this?


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2020-01-03 18:31:06

cubethethird
Member
Registered: 2016-01-25
Posts: 61
Website

Re: How to treat global files as user local files

Thanks for the response. The game is actually open source. It's a fork of the game Brogue, called Brogue Community Edition. It's written in C though, which is why I'd rather not touch the source. As I said, I could submit a request to add that functionality.
I suppose copying the application itself could be an option, as the entire directory would only amount to a few megabytes.

Offline

#4 2020-01-03 19:25:05

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: How to treat global files as user local files

I just checked, and there is nothing in that to change to or detect the directory that the program is installed in (as I suspected as this is not trival to do).  It just reads and writes to the current working directory ... but it does also assume that all of it's resources are in the current working directory which is ... well, completely fucking stupid and will not work at all under most conditions in which executables are launched.

I'd just put a script in /usr/bin much like what I had above except instead of copying, just create symlinks under $HOME to the binary and the assets directory (and copy the keymap.txt), then run the symlink.

Last edited by Trilby (2020-01-03 19:33:07)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#5 2020-01-05 05:10:46

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: How to treat global files as user local files

Another common tactic is having a launcher script which will "cd /opt/thegame && exec ./progname".

By convention, because people who develop games tend to be... clumsy like this... the "games" user/group exists so that you can make files/directories writable by said user/group, and then the advice is that users who wish to play the game should make sure they are added to the "games" group.

It's not a very *nice* workaround...


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#6 2020-01-05 05:30:35

cubethethird
Member
Registered: 2016-01-25
Posts: 61
Website

Re: How to treat global files as user local files

Thanks for the suggestions. For the time being, I've gone with the symlink route. I'll also make a request that the project be modified to enable this functionality, as that would be most ideal.

Offline

#7 2020-01-05 05:45:56

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: How to treat global files as user local files

https://github.com/tmewett/BrogueCE/issues/27

I'd also suggest that it default to storing configs in $XDG_CONFIG_HOME/brogue-ce ($XDG_CONFIG_HOME if unset should default to $HOME/.config) or $XDG_DATA_HOME (.local/share/), depending.

This would make it work out of the box.

If storing it in the same directory as the binary is actually considered desirable, then it should probably be platform-dependent, or conditional on being built with a compilation flag such as "PORTABLE := YES" in the config.mk I see. (This would define a suitable C ifdef.)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

Board footer

Powered by FluxBB