978cbf9360
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
14 lines
381 B
Text
14 lines
381 B
Text
test basic
|
|
# Simple test case for development
|
|
|
|
test initial bisync
|
|
bisync resync
|
|
bisync resync ignore-listing-checksum
|
|
|
|
test place newer files on both paths
|
|
# force specific modification time since file time is lost through git
|
|
touch-copy 2001-01-02 {datadir/}file1.txt {path2/}
|
|
copy-as {datadir/}file1.txt {path1/}subdir file20.txt
|
|
|
|
test bisync run
|
|
bisync ignore-listing-checksum
|