Bi-directional syncing not working on two devices

[KayDox64]

Now I don't know if I'm an idiot, and totally misunderstanding the point of this program, but I can't get bi-directional syncing to work on two devices. Example being I play game on computer A, save syncs to One drive, try to play game on computer b with same directory setup, and I get an error asking me if the log files exist (they do). I'll delete the lock files to make new files, and then it sinks again but it doesn't download the new data anymore. If I sync computer b data, then try to resync on computer A again, same issue. Don't really know what I'm doing wrong, unless I've misunderstood what this program is supposed to be for.

[GedasFX]

I don't think I fully understand the issue you are having here, bi-sync should upload and download on steam deck specifically. Path overrides do not work but there are no plans to override that.

[AkazaRenn]

Possibilu due to this error

ERROR : Local file system at /: not deleting directories as there were IO errors
ERROR : Bisync critical error: chtimes /home: operation not permitted

After rclone pulls the changes made on system 1 to system 2, it wants to do chtimes on all the folders it's syncing as a way to track the changes. And obviously it doesn't have the permission to do that on /home and causes it to error.

A workaround might be instead of /, use ${HOME} as the starting point, that would assure that the files being synced can be modified by rclone. It requires change on the code and would break current syncs. We can probably append ${HOME} to the end of the cloud destination during update to fix that. This would also disable the ability for users to sync any file out of their home folder, but I think the impact is minor.

@GedasFX how do you think?

[GedasFX]

Yeah this is tricky... In a way we could have like the plugin directory or home directory or something and use it as aliases? Every time you add a new path it would make an alias in some private directory. Could also let the users rename it however they would please.

But this is a serious development and a breaking change.

I guess it would be possible to just create a symlink recursively in some private /home/deck/.local/decky-cloud-save cache folder, and then just use that as root instead of /, and during migration create symlinks based on paths. This would also fix the .steam folder nonsense.

The impact of disabling sync outside of folder is a big deal, as it would prevent syncing SD card data. Now you could tell users to setup symlinks, which... actually it might work too, more work but would work.

As an actual solution, that I guess would be able to work, would be to add ability to change root directory. Would be simple enough, and would need to be documented EXTRA clear that it would break existing backups as it would change the structure. But it would work with symlinks, and I do believe they work.

[GedasFX]

While I do not like how patchworky this feature feels, I don't really see an alternative. This only really breaks bisync, which is considered an advanced feature, I can let it slide.

Ideally I would like to have a path manager inside, but I personally would like to leave that as an exercise for another person to implement :D

[GedasFX]

In a way, if I can get this to work, with symlinks, you could add support for #45 (even though PR is active already). Would keep the plugin away from feature creep.

Can also be a way of implementing #86, #92 (ish)

[AkazaRenn]

@GedasFX if we change the root to $HOME, to sync the SD card, maybe we can add a validation when a path is added and do this:

1. If the path is within $HOME, pass
2. Otherwise, if it's in /dev/, offer to create symlinks for the drives to like ${HOME}/.dev/sda1, we can get all drives created at once
3. For other possibilities, reject

Actually 2 can be done when the user tries to enable bisync. Would be better done when adding paths to catch the hardware changes.

If you agree I can bring this to my PR https://github.com/GedasFX/decky-cloud-save/pull/83 since we'll need a config migration anyways, and that's a one time thing so it would be less hassle in the future.

[GedasFX]

@AkazaRenn I'm thinking even more simply. If path is within to whatever user specified in config - pass. Then just let user deal with the stuff by themselves. Am not really that interested in eventually getting a ticket about someone saying that my naming is wrong or something... DO IT YOURSELF THEN!!! XD

The hard part here is I would need to rework the generation of filter path as the paths there are relative to root, it was just a coincidence it worked, as my root was /.

By default the SD card if memory serves correctly goes to /media/jibberish. So even then its not reliable source. Letting users customize this entirely by the tools built into OS itself is likely best regardless.

[GedasFX]

I simply do not feel all that confident about all the potential issues that may arise here... Simple solution is enticing because 1) its simple, and 2) its intuitive for the user. Having magic code that creates folders in unknown locations without much digging feels wrong.

[GedasFX]

Oh yeah and I also know some people who use this plugin to just back up config files so /etc would need to be included in check and honestly this would get ugly real fast...

I will try verify if symlinks work in the first place, and if they do - maybe prototype a config option for root dir

[AkazaRenn]

@GedasFX I agree with you that simply rejecting non $HOME entries are the easiest solution. We only need to get the rejection clear enough for the user to figure out why, like a link to a document.

As for the sync paths, we can just remove the /home/deck before each of them, so I think the only problem is the existing non-${HOME} sync paths the user has right now, That might has to be broken first, or during process, if we find such a path, we can pop the same explaining dialogue, so it should only happen when the plugin is updated?

[GedasFX]

Nono what I mean is that the feature is opt in. If user actively and consciously changed the root path to be some other folder, my expectation is that they are aware that they... did.. that 😄. It will not be an automated process.

If we want to also do this as desired in #86, we would also need to not limited to just home, but whatever user chooses. We can suggest /home/deck, but that suggestion is sufficient in readme.

And since the path changing process is manual (for now, will see if feature warrants proper UI), we can just leave a warning for user to just recreate all start paths or edit the files manually. Documentation should be more than enough here

[AkazaRenn]

@GedasFX oh I got it now. Sure that would be ideal too! Then all the processing can be kept within when the user changes the sync root. Since the sync root can be changed from a random path A to a random path B, we might need a serious warning when that happens, and everything else can be left to the user... Or we don't expose it to the frontend at all, so only those who has read the document can do it?

[GedasFX]

Yeah sounds perfect. For a quick solution we can add it as just documented advanced feature, and if people want this more integrated, we can expand on it in future.

Other than that I think the road is clear, will begin my experimenting shortly ^^