What is the intended behavior of Cloud Sync? #436
Replies: 1 comment
-
Hi! This is definitely a shortcoming of the cloud functionality as it stands today. I would say the main purpose is to serve as a redundant backup, but it is also meant to support cross-system sync, although it's not as streamlined as it probably should be. Right now, when switching systems like this, you're just supposed to open Ludusavi and perform a download on the "other" screen manually, which I understand isn't so convenient. Since you're using For what you're trying to do, I know some people recommend Syncthing, although I haven't used it myself. |
Beta Was this translation helpful? Give feedback.
-
tl;dr
Is the intended behavior of cloud sync just to create a redundant back up? Is there no way of having ludusavi restore from the cloud path TO the local path as part of the restore process?
I've been working for the last several days on getting automatic cross-platform save synchronization set up between my Steam Deck and my Windows desktop using ludusavi. For the most part, I have gotten this set up to work well; I push data using the file structure on my Steam Deck into Dropbox. Dropbox then appears as a folder on Windows, where I can pull the data from using bidirectional redirects to unmap the linux/Proton/etc paths back into the desired locations on my Windows desktop.
When I originally set this up, I used the cloud saves functionality in ludusavi to push my deck backups to my Dropbox via rclone. I encountered a problem with bidirectional communication with this method, however.
Suppose I recover a save on Deck, modify it, and then back it up again on game close using a launch wrapper. That works fine.
Now, on my desktop PC, I can open the same game using a launch wrapper, and it will recover the cloud save, let me modify it, and then back it up again on close.
Now, when I reopen the save on Deck, we have an issue. See, the Deck copies its local backup structure to the cloud, but it only RECOVERS from its local recovery structure. It will automatically attempt a cloud sync upload when it backs up, but it won't attempt a cloud sync download when it recovers.
So, now the saves are out of sync. And they will stay that way, because now, when the Deck further modifies the save and backs it up, it will detect that the local backup and cloud backup are no longer identical at the start of backup (one has the last Deck local save at the time of the last backup, the other has the save that was modified on Windows instead), and it will cancel the cloud sync until those files are manually resynchronized. So my local save is there in the local path, but not the cloud; and if I recover again on Windows, I will have reverted to the first original Deck save and lose progress.
So, I think to myself, the solution here is to replicate the Windows behavior on Deck. Restoring from-cloud works on Windows because the cloud saves are an actual recovery path, not a separate cloud backup. So I configure rclone to mount my Dropbox as a path on the Deck's filesystem itself. This takes a bit of doing with a startup service to ensure it's always active, but it does work. I can now recover directly from the cloud path, rather than the local path.
And this works... but then it doesn't. Because now the Steam Deck can't save locally.
See, the save that is recovered from the cloud is pushed directly to the main save location for the game in question. But it's still not pushed to the ludusavi local save backup location. So when ludusavi goes to perform the back-up from the local location to the cloud... it once again detects that the files are not in sync. And refuses to push the local save to the cloud save. The local save backup and cloud save backup are still desynced, because ludusavi can only PUSH files to the cloud automatically via rclone, it doesn't PULL them.
The final, most obvious fix is to just use the mount path for both the back up and recover location. And this does, indeed, "work". The problem is, rclone as a mount point is significantly slower than using sync, since rclone mounts cannot make use of --fast-list. It takes on the order of 20 seconds to complete the backup of a single game save on game exit. And crucially, during this time, ludusavi does not lock Steam in any way or self-check during this time. So if you restart the game before that 20 seconds is up, you can wind up re-copying the existing save to the local path from the cloud, and permanently erasing what you were trying to push TO the cloud. This isn't an issue when the backup happens on the order of a second or less and it's using local caching but is a huge problem in this context.
So what I am asking, after all this backstory, is the following:
Is the intended behavior of cloud sync just to create a redundant back up? Is there no way of having ludusavi restore from the cloud path TO the local path as part of the restore process?
Because if you can only restore from the cloud manually, that locks you into using mountpoints for bidirectional cloud sync, and rclone simply is not optimized to handle mountpoints as well as it's optimized to handle regular data duplication in either direction.
Beta Was this translation helpful? Give feedback.
All reactions