nielash 978cbf9360 bisync: generate final listing from sync results, not relisting -- fixes #5676 ... Before this change, if there were changes to sync, bisync listed each path twice: once before the sync and once after. The second listing caused quite a lot of problems, in addition to making each run much slower and more expensive. A serious side-effect was that file changes could slip through undetected, if they happened to occur while a sync was running (between the first and second listing snapshots.) After this change, the second listing is eliminated by getting the underlying sync operation to report back a list of what it changed. Not only is this more efficient, but also much more robust to concurrent modifications. It should no longer be necessary to avoid make changes while it's running -- bisync will simply learn about those changes next time and handle them on the next run. Additionally, this also makes --check-sync usable again. For further discussion, see: https://forum.rclone.org/t/bisync-bugs-and-feature-requests/37636#:~:text=5.%20Final%20listings%20should%20be%20created%20from%20initial%20snapshot%20%2B%20deltas%2C%20not%20full%20re%2Dscans%2C%20to%20avoid%20errors%20if%20files%20changed%20during%20sync		2024-01-20 14:50:08 -05:00
..
canonical.go	bisync: generate final listing from sync results, not relisting -- fixes #5676	2024-01-20 14:50:08 -05:00
files.go	Replace deprecated ioutil	2022-11-07 11:41:47 +00:00
names.go	Replace deprecated ioutil	2022-11-07 11:41:47 +00:00
output.go	bisync: implementation #5164	2021-11-01 21:00:27 +03:00