I think rclone::bisync doesn't recognize when a resync already happened with the local/remote paths reversed.
For example, suppose I have a local path at
/home/me/Documents and a remote as
MyRemote:/. When bisync fails and I'm forced to do a resync, the order matters. Sometimes I might want to overwrite local changes by placing the remote as Path1 and the local as Path2. Other times I might want to overwrite remote changes by placing the local as Path1, and the remote as Path2.
This all seems fine until I run my normal bash script with the order hard-coded, and rclone::bisync seems not to recognize that a resync has occurred because the previous resync might have had the paths in a different order.
I get why the order matters for a resync, but I feel it shouldn't matter for the subsequent bisync, since a bisync goes in both directions.
For the moment I'm solving this problem by running resync twice (once in each direction) when my preferred resync order doesn't match the bisync's order. However this is obviously a slight waste of time so I'm wondering if there are any plans (or any current method) to help rclone identify previous successful resyncs even if the order was different.
rclone v1.58.1 - os/version: ubuntu 22.04 (64 bit) - os/kernel: 5.15.0-33-generic (x86_64) - os/type: linux - os/arch: amd64 - go/version: go1.17.9 - go/linking: static - go/tags: none
Google Drive and DropBox
Notice the paths having a different order.
rclone bisync --progress --check-access --transfers 25 --resync --force --localtime "/home/me/Documents/REDACTED" REDACTED_DropBox_Encrypted:"/"
rclone bisync --progress --check-access --transfers 25 --force --localtime REDACTED_DropBox_Encrypted:"/" "/home/me/Documents/REDACTED"
Mostly n/a; I just get the standard complaint about not finding Path listings
2022-05-31 23:32:28 ERROR : Bisync critical error: cannot find prior Path1 or Path2 listings, likely due to critical error on prior run 2022-05-31 23:32:28 ERROR : Bisync aborted. Must run --resync to recover.