Can redirects be used to override the backup structure?

[RhythmScript]

when configuring ludusavi, you can configure redirects which map one file location to a different file location on backup, and then reverse this process on restore. In principle, this is very handy for keeping save files synchronized correctly between devices with different file trees. But this doesn't actually seem to be what ludusavi DOES, at least not really, because of the backup structure itself... can this be changed?

e.g. suppose I want to back up a file from C:/Games/Example/Path to D:/Games/Example/Alt
I can, in principle, set up a redirect between these two folder locations prior to running the backup, to ensure the file is mapped correctly. However, if you actually RUN the backup, the file doesn't get copied to D:/Games/Example/Alt. It will instead get copied to
D:/GameName/drive-1-D/Games/Example/Alt (provided D:/ is the backup destination). There doesn't seem to be any way to stop this. In the backup preview, ludusavi will SAY it's backing up a file to "D:/Games/Example/Alt" it just doesn't actually put the file there.

I guess this is intended behavior, at least per the docs explaining the backup structure? But is there no way around it? The problem with it is, if you have save files you want to keep in sync with ludusavi from any other context or source, you must FORCE that source to obey ludusavi's particular file tree structure, which seems to go against the point of the redirects. If I have used some other software or program or whatever to push save files to a structure (say, from another device using syncthing, rclone, etc), I'd like to use ludusavi to pull files from that structure. But I can't do that, because ludusavi will always treat redirects as starting from an encapsulation that it defines on a per-game basis.

As a hack-around, I'd have to force that other software to push the files into a structure using ludusavi's game name prefixes and drive IDs, and then essentially just lie to ludusavi about the location of those save files so it would "redirect" from its own version of the file structure correctly.

I feel like I'm misunderstanding some key element of how this process is supposed to work.

[mtkennerly]

Hi! As you observed, Ludusavi does expect the backup folder to be something that it controls and can use a specific layout/metadata format. When you configure a redirect from C:/foo to D:/bar, Ludusavi will treat it as D:/bar in the backup metadata, but will not create/overwrite the real D:/bar folder until you perform a restore. When you perform a restore, the metadata (and/or your redirect config) will then cause it to restore to D:/bar instead of the original location.

If I have used some other software or program or whatever to push save files to a structure (say, from another device using syncthing, rclone, etc), I'd like to use ludusavi to pull files from that structure.

What I would recommend for this is:

• On your different computers, have Syncthing/etc synchronize Ludusavi's backup folder
• If Syncthing/etc can run a script after syncing, then have it execute ludusavi restore --force (plus whatever other options you need) to restore the files onto each system

[RhythmScript]

Yeah, unfortunately that is what I had to do, I basically rewrote the file structure the other software was using to expect "GameName/drive-0/" as the top level folders, and told Ludusavi NOT to expect that. A bit cumbersome but it essentially works. The issue for my specific use case is that this type of behavior is common among many backup based systems, where they all just hardcode some assumption about the file structure. In my case (trying to use a Decky extension for managing Steam Deck backups, due to limitations with ludusavi cli-wrapping in that environment) the extension needed the backup structure to match the file structure relative to the root, which of course is NOT how the actual saves are stored. So one piece of software wants the backups to match the pattern of the file tree where they were drawn from, and the other one explicitly wants them NOT to do that because they need to be prefixed on a game-by-game basis.

What I ended up having to do was create a local copy of the ludusavi backup location's actual file structure on the Steam Deck, and just fill it with symlinks pointed to the actual save locations, so that the Decky extension could march that structure, point itself to the actual save files, and back them up to a 1:1 copy to the tree format that ludusavi would use. Then I told ludusavi I was using a different tree structure, so it would actually generate the tree structure I was using and back up from it correctly. Which, IMHO, is a lot of telling lies to computer programs just to get a file copied from one path to another path automatically, but at the end of the day it works.