github-mirror/rclone
2
0
Fork 0
mirror of https://github.com/rclone/rclone.git synced 2024-12-12 20:33:50 +08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity
b4216648e4
rclone/cmd/bisync/testdata/test_volatile/scenario.txt

35 lines
1023 B
Plaintext
Raw Normal View History

bisync: rollback listing on error Before this change, bisync had no mechanism for "retrying" a file again next time, in the event of an unexpected and possibly temporary error. After this change, bisync is now essentially able to mark a file as needing to be rechecked next time. Bisync does this by keeping one prior listing on hand at all times. In a low-confidence situation, bisync can revert a given file row back to its state at the end of the last known successful sync, ensuring that any subsequent changes will be re-noticed on the next run. This can potentially be helpful for a dynamically changing file system, where files may be changing quickly while bisync is working with them.
2023-10-07 04:38:47 +08:00
test volatile
test initial bisync
bisync resync
test changed on both paths - file5 (file5R, file5L)
touch-glob 2001-01-02 {datadir/} file5R.txt
bisync: account for differences in backend features on integration tests - see #5679 Before this change, integration tests often could not be run on backends with differing features from the local system that goldenized them. In particular, differences in modtime precision, checksum support, and encoding would cause false positives. After this change, the tests more accurately account for the features of the backend being tested, which allows us to see true positives more clearly, and more meaningfully assess whether a backend is supported.
2023-11-18 01:14:38 +08:00
touch-glob 2023-08-26 {datadir/} file7.txt
bisync: rollback listing on error Before this change, bisync had no mechanism for "retrying" a file again next time, in the event of an unexpected and possibly temporary error. After this change, bisync is now essentially able to mark a file as needing to be rechecked next time. Bisync does this by keeping one prior listing on hand at all times. In a low-confidence situation, bisync can revert a given file row back to its state at the end of the last known successful sync, ensuring that any subsequent changes will be re-noticed on the next run. This can potentially be helpful for a dynamically changing file system, where files may be changing quickly while bisync is working with them.
2023-10-07 04:38:47 +08:00
copy-as {datadir/}file5R.txt {path2/} file5.txt
touch-glob 2001-03-04 {datadir/} file5L.txt
copy-as {datadir/}file5L.txt {path1/} file5.txt
test bisync with 50 files created during - should ignore new files
test-func
bisync
test changed on both paths - file5 (file5R, file5L)
touch-glob 2001-01-02 {datadir/} file5R.txt
copy-as {datadir/}file5R.txt {path2/} file5.txt
touch-glob 2001-03-04 {datadir/} file5L.txt
copy-as {datadir/}file5L.txt {path1/} file5.txt
test next bisync - should now notice new files
test-func
bisync
test changed on both paths - file5 (file5R, file5L)
touch-glob 2001-01-02 {datadir/} file5R.txt
copy-as {datadir/}file5R.txt {path2/} file5.txt
touch-glob 2001-03-04 {datadir/} file5L.txt
copy-as {datadir/}file5L.txt {path1/} file5.txt
test next bisync - should be no changes except dummy
test-func
bisync
Reference in New Issue Copy Permalink