Add option to translate Wine prefixes across OSes

[mtkennerly]

What's your idea?

This was proposed in https://github.com/mtkennerly/ludusavi/issues/156#issuecomment-1496330814.

mapping.yaml could contain some additional fields on each backup:

• os (string)
• wine_prefixes (list of paths)

Use cases:

• Back up on Linux, restore on Windows
  • mapping.yaml contains paths like drive-0/home/<user>/Games/prefixname/drive_c/users/<user>/AppData/Local/game
  • wine_prefixes would have an entry for drive-0/home/<user>/Games/prefixname
  • When we restore a file that starts with a Wine prefix path, we would translate it to the normal Windows location for the current user
  • We would need to parse Wine's *.reg files so that we can directly restore the relevant keys to the registry (right now, we just back up the *.reg files as a whole)
• Back up on Windows, restore on Linux
  • mapping.yaml contains paths like drive-C/users/<user>/AppData/Local/game
  • There would be some way for the user to configure a preferred prefix for each game to restore into
  • When we restore the backup, if the game has a preferred prefix, then translate the file paths into their Wine equivalents and create/edit the *.reg files

This would also allow us to show a badge on non-native backups or add an option to prevent restoration unless they can be translated/redirected.

[danepowell]

Would this also solve the use case of syncing Wine games Linux to Linux, where each machine has a different user name? Currently you can set a redirect for /home/user on each machine, but the problem is the username is also encoded in the path drive_c/users/user in the wine prefix. Unless you create a separate redirect for every game, I don't see how to fix that.

[mtkennerly]

Ah, that's an interesting case. I think that would need a different solution, since it's a path inside of the Wine prefix rather than the prefix as a whole.

One option would be to add some kind of Wine-specific redirect support or even more specifically just to handle usernames. A more general, but slower/advanced solution could be to add support for redirects using regular expressions with capture groups. Then you might have something like:

• For backups:
  • Source: ^(.*/drive_*/users/)actual-username(/.*)?$
  • Target: ${1}standardized-name${2}
• For restores:
  • Source: ^(.*/drive_*/users/)standardized-name(/.*)?$
  • Target: ${1}actual-username${2}

[danepowell]

I agree the regex solution seems best. Shall I open a new ticket for that?

[mtkennerly]

Sure, that would be great :)

[Mike3137]

I'm sure you have thought about it and there is a good reason why you don't do it this way. But why aren't the backups made with a relative path instead of absolute path of the source machine.

Like if the save path is $XDG_CONFIG_HOME/game/save.sav the backup folders could be something like /backupfolder/gametitle/xdg_config_home/game/save.sav instead of /backupfolder/gametitle/drive-0/home/username/.config/game/save.sav.

This way it would be possible to restore on a different computer, right now I always have to manually edit the backup folders and yaml to match the target machine's paths before restoring.

I guess you would have to select where to restore each relative path, especially for wine prefixes. But for most other cases the default should be fine.

[mtkennerly]

@Mike3137 There are some complications with that approach:

• What if you make a backup with a non-Flatpak version of Ludusavi and then restore with the Flatpak version? The XDG paths will point to Ludusavi's Flatpak directory, which probably isn't where you'd want to restore the saves.
  • The XDG paths could also change unexpectedly when Ludusavi is launched by another program, like if you use Heroic and set up Ludusavi as a wrapper command. Heroic overrides the XDG variables.
• What if you make a backup that includes files from multiple system users? Each user has their own XDG paths.

By using absolute paths for everything, Ludusavi can ensure that a save backed up from one location will always restore to the same location on the same system.

That said, you could use the redirect feature to do something like you described. For example, you could define this on each of your systems (just changing the username):

right now I always have to manually edit the backup folders and yaml to match the target machine's paths before restoring.

You can use the redirect feature to make this a lot easier. If the main issue is the username, then this might be all you need:

[JoshElias]

@mtkennerly This might not be the best place to ask this question but does Ludusavi currently support Windows <-> Linux backup and restoration?

I just tried doing a backup on my Windows machine and restoring on my Linux and they all failed due to the path names being too long.

[mtkennerly]

@JoshElias It does support it, but you have to set up redirects (on the "other" screen), so it's a bit limited. It's not automatic because it's hard to say exactly where a Linux path should restore on Windows and vice versa.

A simple (but not exactly correct) example: on Linux, you could set up a restore redirect from C:\ to /windows/c, and on Windows, you could set up a restore redirect from / to C:\.

To be more correct, you'd probably want to set up specific redirects like /home -> C:\Users. However, even then, there might be a game that uses fundamentally different save paths on different OSes. For example, according to PCGamingWiki, Celeste uses <path-to-game>\Saves on Windows, but $XDG_DATA_HOME/Celeste/Saves on Linux.

[Nicoxys]

@mtkennerly Have you any plan to add some magic into ludusavi to support this automatically? Or it's hard to the point it cannot be done? Even if only for syncing non-steam windows game (proton) in steamOS and windows games on windows system.

I mean, if ludusavi can recognize my non-steam games based on their name matching pcgamingwiki info (and it seems to do so), probably it can sort things out in some way.

Thank you for your effort

[mtkennerly]

@Nicoxys I do still want to try to support it, but since it is quite a difficult feature, I don't have a specific timeline in mind.

[happyme531]

I am also wondering why Ludusavi use full/absolute path for storing backup, which seems unnesserary and is causing trouble now.

By using absolute paths for everything, Ludusavi can ensure that a save backed up from one location will always restore to the same location on the same system.

It seems better to store the savefile content in relative manner, and store the necessary perfix information per-system in the metadata file.