github-mirror/rclone
2
0
Fork 0
mirror of https://github.com/rclone/rclone.git synced 2024-12-23 12:13:48 +08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity
d031cc138d
rclone/cmd/bisync/testdata/test_extended_filenames/golden/test.log

118 lines
8.8 KiB
Plaintext
Raw Normal View History

bisync: introduce terminal colors This introduces a few basic color codings to make the terminal output more readable (and more fun). Rclone's standard --color flag is supported. (AUTO|NEVER|ALWAYS) Only a few lines have colors right now -- more will probably be added in future versions.
2023-11-06 19:59:41 +08:00
(01) : test extended-filenames
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
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
(02) : fix-names {path1/}subdir_with_ࢺ_/
(03) : fix-names {path2/}subdir_with_ࢺ_/
(04) : fix-names {path1/}subdir_with_ࢺ_/filename_contains_ě_.txt
(05) : fix-names {path2/}subdir_with_ࢺ_/filename_contains_ě_.txt
(06) : fix-names {path1/}Русский.txt
(07) : fix-names {path2/}Русский.txt
(08) : fix-names {path1/}file_enconde_mañana_funcionará.txt
(09) : fix-names {path2/}file_enconde_mañana_funcionará.txt
(10) : test initial bisync
(11) : bisync resync
bisync: full support for comparing checksum, size, modtime - fixes #5679 fixes #5683 fixes #5684 fixes #5675 Before this change, bisync could only detect changes based on modtime, and would refuse to run if either path lacked modtime support. This made bisync unavailable for many of rclone's backends. Additionally, bisync did not account for the Fs's precision when comparing modtimes, meaning that they could only be reliably compared within the same side -- not against the opposite side. Size and checksum (even when available) were ignored completely for deltas. After this change, bisync now fully supports comparing based on any combination of size, modtime, and checksum, lifting the prior restriction on backends without modtime support. The comparison logic considers the backend's precision, hash types, and other features as appropriate. The comparison features optionally use a new --compare flag (which takes any combination of size,modtime,checksum) and even supports some combinations not otherwise supported in `sync` (like comparing all three at the same time.) By default (without the --compare flag), bisync inherits the same comparison options as `sync` (that is: size and modtime by default, unless modified with flags such as --checksum or --size-only.) If the --compare flag is set, it will override these defaults. If --compare includes checksum and both remotes support checksums but have no hash types in common with each other, checksums will be considered only for comparisons within the same side (to determine what has changed since the prior sync), but not for comparisons against the opposite side. If one side supports checksums and the other does not, checksums will only be considered on the side that supports them. When comparing with checksum and/or size without modtime, bisync cannot determine whether a file is newer or older -- only whether it is changed or unchanged. (If it is changed on both sides, bisync still does the standard equality-check to avoid declaring a sync conflict unless it absolutely has to.) Also included are some new flags to customize the checksum comparison behavior on backends where hashes are slow or unavailable. --no-slow-hash and --slow-hash-sync-only allow selectively ignoring checksums on backends such as local where they are slow. --download-hash allows computing them by downloading when (and only when) they're otherwise not available. Of course, this option probably won't be practical with large files, but may be a good option for syncing small-but-important files with maximum accuracy (for example, a source code repo on a crypt remote.) An additional advantage over methods like cryptcheck is that the original file is not required for comparison (for example, --download-hash can be used to bisync two different crypt remotes with different passwords.) Additionally, all of the above are now considered during the final --check-sync for much-improved accuracy (before this change, it only compared filenames!) Many other details are explained in the included docs.
2023-12-01 08:44:38 +08:00
INFO : Setting --ignore-listing-checksum as neither --checksum nor --compare checksum are set.
INFO : Bisyncing with Comparison Settings:
{
"Modtime": true,
"Size": true,
"Checksum": false,
"NoSlowHash": false,
"SlowHashSyncOnly": false,
"DownloadHash": false
}
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
INFO : Synching Path1 "{path1/}" with Path2 "{path2/}"
INFO : Copying unique Path2 files to Path1
bisync: optimize --resync performance -- partially addresses #5681 Before this change, --resync was handled in three steps, and needed to do a lot of unnecessary work to implement its own --ignore-existing logic, which also caused problems with unicode normalization, in addition to being pretty slow. After this change, it is refactored to produce the same result much more efficiently, by reducing the three steps to two and letting ci.IgnoreExisting do the work instead of reinventing the wheel. The behavior and sync order remain unchanged for now -- just faster (but see the ongoing lively discussions about potential future changes in #5681!)
2023-11-06 23:34:47 +08:00
INFO : - Path2 Resync is copying UNIQUE files to - Path1
bisync: full support for comparing checksum, size, modtime - fixes #5679 fixes #5683 fixes #5684 fixes #5675 Before this change, bisync could only detect changes based on modtime, and would refuse to run if either path lacked modtime support. This made bisync unavailable for many of rclone's backends. Additionally, bisync did not account for the Fs's precision when comparing modtimes, meaning that they could only be reliably compared within the same side -- not against the opposite side. Size and checksum (even when available) were ignored completely for deltas. After this change, bisync now fully supports comparing based on any combination of size, modtime, and checksum, lifting the prior restriction on backends without modtime support. The comparison logic considers the backend's precision, hash types, and other features as appropriate. The comparison features optionally use a new --compare flag (which takes any combination of size,modtime,checksum) and even supports some combinations not otherwise supported in `sync` (like comparing all three at the same time.) By default (without the --compare flag), bisync inherits the same comparison options as `sync` (that is: size and modtime by default, unless modified with flags such as --checksum or --size-only.) If the --compare flag is set, it will override these defaults. If --compare includes checksum and both remotes support checksums but have no hash types in common with each other, checksums will be considered only for comparisons within the same side (to determine what has changed since the prior sync), but not for comparisons against the opposite side. If one side supports checksums and the other does not, checksums will only be considered on the side that supports them. When comparing with checksum and/or size without modtime, bisync cannot determine whether a file is newer or older -- only whether it is changed or unchanged. (If it is changed on both sides, bisync still does the standard equality-check to avoid declaring a sync conflict unless it absolutely has to.) Also included are some new flags to customize the checksum comparison behavior on backends where hashes are slow or unavailable. --no-slow-hash and --slow-hash-sync-only allow selectively ignoring checksums on backends such as local where they are slow. --download-hash allows computing them by downloading when (and only when) they're otherwise not available. Of course, this option probably won't be practical with large files, but may be a good option for syncing small-but-important files with maximum accuracy (for example, a source code repo on a crypt remote.) An additional advantage over methods like cryptcheck is that the original file is not required for comparison (for example, --download-hash can be used to bisync two different crypt remotes with different passwords.) Additionally, all of the above are now considered during the final --check-sync for much-improved accuracy (before this change, it only compared filenames!) Many other details are explained in the included docs.
2023-12-01 08:44:38 +08:00
INFO : - Path1 Resync is copying UNIQUE OR DIFFERING files to - Path2
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
INFO : Resync updating listings
bisync: introduce terminal colors This introduces a few basic color codings to make the terminal output more readable (and more fun). Rclone's standard --color flag is supported. (AUTO|NEVER|ALWAYS) Only a few lines have colors right now -- more will probably be added in future versions.
2023-11-06 19:59:41 +08:00
INFO : Bisync successful
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
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
(12) : test place a newer files on both paths
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
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
(13) : touch-glob 2001-01-02 {datadir/} file1.txt
(14) : touch-glob 2001-01-02 {datadir/} file2.txt
(15) : copy-as {datadir/}file1.txt {path2/} New_top_level_mañana_funcionará.txt
(16) : copy-as {datadir/}file1.txt {path2/} file_enconde_mañana_funcionará.txt
(17) : copy-as {datadir/}file1.txt {path1/} filename_contains_ࢺ_p1m.txt
(18) : copy-as {datadir/}file1.txt {path2/} Русский.txt
(19) : copy-as {datadir/}file1.txt {path1/} file1_with{spc}white{spc}space.txt
(20) : copy-as {datadir/}file1.txt {path1/}subdir_with_ࢺ_ test.txt
(21) : copy-as {datadir/}file1.txt {path1/}subdir_with_ࢺ_ mañana_funcionará.txt
(22) : copy-as {datadir/}file1.txt {path1/}subdir_with_ࢺ_ file_with_測試_.txt
(23) : copy-as {datadir/}file1.txt {path2/}subdir_with_ࢺ_ filename_contains_ࢺ_p2s.txt
(24) : copy-as {datadir/}file1.txt {path2/}subdir{spc}with{eol}white{spc}space.txt file2{spc}with{eol}white{spc}space.txt
(25) : copy-as {datadir/}file1.txt {path2/}subdir_rawchars_{chr:19}_{chr:81}_{chr:fe} file3_{chr:19}_{chr:81}_{chr:fe}
(26) : fix-names {path2/}subdir{spc}with{eol}white{spc}space.txt/file2{spc}with{eol}white{spc}space.txt
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
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
(27) : test place a new file on both paths
(28) : copy-as {datadir/}file2.txt {path2/}subdir_with_ࢺ_ filechangedbothpaths_ࢺ_.txt
(29) : touch-glob 2001-01-03 {datadir/} file1.txt
(30) : copy-as {datadir/}file1.txt {path1/}subdir_with_ࢺ_ filechangedbothpaths_ࢺ_.txt
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
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
(31) : test delete files on both paths
(32) : delete-file {path2/}filename_contains_ࢺ_.txt
(33) : delete-file {path2/}subdir_with_ࢺ_/filename_contains_ě_.txt
(34) : delete-file {path1/}Русский.txt
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
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
(35) : test bisync run
(36) : bisync
bisync: full support for comparing checksum, size, modtime - fixes #5679 fixes #5683 fixes #5684 fixes #5675 Before this change, bisync could only detect changes based on modtime, and would refuse to run if either path lacked modtime support. This made bisync unavailable for many of rclone's backends. Additionally, bisync did not account for the Fs's precision when comparing modtimes, meaning that they could only be reliably compared within the same side -- not against the opposite side. Size and checksum (even when available) were ignored completely for deltas. After this change, bisync now fully supports comparing based on any combination of size, modtime, and checksum, lifting the prior restriction on backends without modtime support. The comparison logic considers the backend's precision, hash types, and other features as appropriate. The comparison features optionally use a new --compare flag (which takes any combination of size,modtime,checksum) and even supports some combinations not otherwise supported in `sync` (like comparing all three at the same time.) By default (without the --compare flag), bisync inherits the same comparison options as `sync` (that is: size and modtime by default, unless modified with flags such as --checksum or --size-only.) If the --compare flag is set, it will override these defaults. If --compare includes checksum and both remotes support checksums but have no hash types in common with each other, checksums will be considered only for comparisons within the same side (to determine what has changed since the prior sync), but not for comparisons against the opposite side. If one side supports checksums and the other does not, checksums will only be considered on the side that supports them. When comparing with checksum and/or size without modtime, bisync cannot determine whether a file is newer or older -- only whether it is changed or unchanged. (If it is changed on both sides, bisync still does the standard equality-check to avoid declaring a sync conflict unless it absolutely has to.) Also included are some new flags to customize the checksum comparison behavior on backends where hashes are slow or unavailable. --no-slow-hash and --slow-hash-sync-only allow selectively ignoring checksums on backends such as local where they are slow. --download-hash allows computing them by downloading when (and only when) they're otherwise not available. Of course, this option probably won't be practical with large files, but may be a good option for syncing small-but-important files with maximum accuracy (for example, a source code repo on a crypt remote.) An additional advantage over methods like cryptcheck is that the original file is not required for comparison (for example, --download-hash can be used to bisync two different crypt remotes with different passwords.) Additionally, all of the above are now considered during the final --check-sync for much-improved accuracy (before this change, it only compared filenames!) Many other details are explained in the included docs.
2023-12-01 08:44:38 +08:00
INFO : Setting --ignore-listing-checksum as neither --checksum nor --compare checksum are set.
INFO : Bisyncing with Comparison Settings:
{
"Modtime": true,
"Size": true,
"Checksum": false,
"NoSlowHash": false,
"SlowHashSyncOnly": false,
"DownloadHash": false
}
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
INFO : Synching Path1 "{path1/}" with Path2 "{path2/}"
bisync: generate listings concurrently with march -- fixes #7332 Before this change, bisync needed to build a full listing for Path1, then a full listing for Path2, then compare them -- and each of those tasks needed to finish before the next one could start. In addition to being slow and inefficient, it also caused real problems if a file changed between the time bisync checked it on Path1 and the time it checked the corresponding file on Path2. This change solves these problems by listing both paths concurrently, using the same March infrastructure that check and sync use to traverse two directories in lock-step, optimized by Go's robust concurrency support. Listings should now be much faster, and any given path is now checked nearly-instantaneously on both sides, minimizing room for error. Further discussion: https://forum.rclone.org/t/bisync-bugs-and-feature-requests/37636#:~:text=4.%20Listings%20should%20alternate%20between%20paths%20to%20minimize%20errors
2023-10-07 18:33:43 +08:00
INFO : Building Path1 and Path2 listings
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
INFO : Path1 checking for diffs
bisync: full support for comparing checksum, size, modtime - fixes #5679 fixes #5683 fixes #5684 fixes #5675 Before this change, bisync could only detect changes based on modtime, and would refuse to run if either path lacked modtime support. This made bisync unavailable for many of rclone's backends. Additionally, bisync did not account for the Fs's precision when comparing modtimes, meaning that they could only be reliably compared within the same side -- not against the opposite side. Size and checksum (even when available) were ignored completely for deltas. After this change, bisync now fully supports comparing based on any combination of size, modtime, and checksum, lifting the prior restriction on backends without modtime support. The comparison logic considers the backend's precision, hash types, and other features as appropriate. The comparison features optionally use a new --compare flag (which takes any combination of size,modtime,checksum) and even supports some combinations not otherwise supported in `sync` (like comparing all three at the same time.) By default (without the --compare flag), bisync inherits the same comparison options as `sync` (that is: size and modtime by default, unless modified with flags such as --checksum or --size-only.) If the --compare flag is set, it will override these defaults. If --compare includes checksum and both remotes support checksums but have no hash types in common with each other, checksums will be considered only for comparisons within the same side (to determine what has changed since the prior sync), but not for comparisons against the opposite side. If one side supports checksums and the other does not, checksums will only be considered on the side that supports them. When comparing with checksum and/or size without modtime, bisync cannot determine whether a file is newer or older -- only whether it is changed or unchanged. (If it is changed on both sides, bisync still does the standard equality-check to avoid declaring a sync conflict unless it absolutely has to.) Also included are some new flags to customize the checksum comparison behavior on backends where hashes are slow or unavailable. --no-slow-hash and --slow-hash-sync-only allow selectively ignoring checksums on backends such as local where they are slow. --download-hash allows computing them by downloading when (and only when) they're otherwise not available. Of course, this option probably won't be practical with large files, but may be a good option for syncing small-but-important files with maximum accuracy (for example, a source code repo on a crypt remote.) An additional advantage over methods like cryptcheck is that the original file is not required for comparison (for example, --download-hash can be used to bisync two different crypt remotes with different passwords.) Additionally, all of the above are now considered during the final --check-sync for much-improved accuracy (before this change, it only compared filenames!) Many other details are explained in the included docs.
2023-12-01 08:44:38 +08:00
INFO : - Path1 File was deleted - Русский.txt
INFO : - Path1 File is new - file1_with white space.txt
INFO : - Path1 File is new - filename_contains_ࢺ_p1m.txt
INFO : - Path1 File is new - subdir_with_ࢺ_/file_with_測試_.txt
INFO : - Path1 File is new - subdir_with_ࢺ_/filechangedbothpaths_ࢺ_.txt
INFO : - Path1 File is new - subdir_with_ࢺ_/mañana_funcionará.txt
INFO : - Path1 File is new - subdir_with_ࢺ_/test.txt
INFO : Path1: 7 changes:  6 new,  0 modified,  1 deleted
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
INFO : Path2 checking for diffs
bisync: full support for comparing checksum, size, modtime - fixes #5679 fixes #5683 fixes #5684 fixes #5675 Before this change, bisync could only detect changes based on modtime, and would refuse to run if either path lacked modtime support. This made bisync unavailable for many of rclone's backends. Additionally, bisync did not account for the Fs's precision when comparing modtimes, meaning that they could only be reliably compared within the same side -- not against the opposite side. Size and checksum (even when available) were ignored completely for deltas. After this change, bisync now fully supports comparing based on any combination of size, modtime, and checksum, lifting the prior restriction on backends without modtime support. The comparison logic considers the backend's precision, hash types, and other features as appropriate. The comparison features optionally use a new --compare flag (which takes any combination of size,modtime,checksum) and even supports some combinations not otherwise supported in `sync` (like comparing all three at the same time.) By default (without the --compare flag), bisync inherits the same comparison options as `sync` (that is: size and modtime by default, unless modified with flags such as --checksum or --size-only.) If the --compare flag is set, it will override these defaults. If --compare includes checksum and both remotes support checksums but have no hash types in common with each other, checksums will be considered only for comparisons within the same side (to determine what has changed since the prior sync), but not for comparisons against the opposite side. If one side supports checksums and the other does not, checksums will only be considered on the side that supports them. When comparing with checksum and/or size without modtime, bisync cannot determine whether a file is newer or older -- only whether it is changed or unchanged. (If it is changed on both sides, bisync still does the standard equality-check to avoid declaring a sync conflict unless it absolutely has to.) Also included are some new flags to customize the checksum comparison behavior on backends where hashes are slow or unavailable. --no-slow-hash and --slow-hash-sync-only allow selectively ignoring checksums on backends such as local where they are slow. --download-hash allows computing them by downloading when (and only when) they're otherwise not available. Of course, this option probably won't be practical with large files, but may be a good option for syncing small-but-important files with maximum accuracy (for example, a source code repo on a crypt remote.) An additional advantage over methods like cryptcheck is that the original file is not required for comparison (for example, --download-hash can be used to bisync two different crypt remotes with different passwords.) Additionally, all of the above are now considered during the final --check-sync for much-improved accuracy (before this change, it only compared filenames!) Many other details are explained in the included docs.
2023-12-01 08:44:38 +08:00
INFO : - Path2 File changed: size (larger), time (newer) - file_enconde_mañana_funcionará.txt
INFO : - Path2 File was deleted - filename_contains_ࢺ_.txt
INFO : - Path2 File was deleted - subdir_with_ࢺ_/filename_contains_ě_.txt
INFO : - Path2 File changed: size (larger), time (newer) - Русский.txt
INFO : - Path2 File is new - New_top_level_mañana_funcionará.txt
INFO : - Path2 File is new - subdir with␊white space.txt/file2 with␊white space.txt
INFO : - Path2 File is new - "subdir_rawchars_␙_\x81_\xfe/file3_␙_\x81_\xfe"
INFO : - Path2 File is new - subdir_with_ࢺ_/filechangedbothpaths_ࢺ_.txt
INFO : - Path2 File is new - subdir_with_ࢺ_/filename_contains_ࢺ_p2s.txt
INFO : Path2: 9 changes:  5 new,  2 modified,  2 deleted
INFO : (Modified:  2 newer,  0 older,  2 larger,  0 smaller)
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
INFO : Applying changes
bisync: full support for comparing checksum, size, modtime - fixes #5679 fixes #5683 fixes #5684 fixes #5675 Before this change, bisync could only detect changes based on modtime, and would refuse to run if either path lacked modtime support. This made bisync unavailable for many of rclone's backends. Additionally, bisync did not account for the Fs's precision when comparing modtimes, meaning that they could only be reliably compared within the same side -- not against the opposite side. Size and checksum (even when available) were ignored completely for deltas. After this change, bisync now fully supports comparing based on any combination of size, modtime, and checksum, lifting the prior restriction on backends without modtime support. The comparison logic considers the backend's precision, hash types, and other features as appropriate. The comparison features optionally use a new --compare flag (which takes any combination of size,modtime,checksum) and even supports some combinations not otherwise supported in `sync` (like comparing all three at the same time.) By default (without the --compare flag), bisync inherits the same comparison options as `sync` (that is: size and modtime by default, unless modified with flags such as --checksum or --size-only.) If the --compare flag is set, it will override these defaults. If --compare includes checksum and both remotes support checksums but have no hash types in common with each other, checksums will be considered only for comparisons within the same side (to determine what has changed since the prior sync), but not for comparisons against the opposite side. If one side supports checksums and the other does not, checksums will only be considered on the side that supports them. When comparing with checksum and/or size without modtime, bisync cannot determine whether a file is newer or older -- only whether it is changed or unchanged. (If it is changed on both sides, bisync still does the standard equality-check to avoid declaring a sync conflict unless it absolutely has to.) Also included are some new flags to customize the checksum comparison behavior on backends where hashes are slow or unavailable. --no-slow-hash and --slow-hash-sync-only allow selectively ignoring checksums on backends such as local where they are slow. --download-hash allows computing them by downloading when (and only when) they're otherwise not available. Of course, this option probably won't be practical with large files, but may be a good option for syncing small-but-important files with maximum accuracy (for example, a source code repo on a crypt remote.) An additional advantage over methods like cryptcheck is that the original file is not required for comparison (for example, --download-hash can be used to bisync two different crypt remotes with different passwords.) Additionally, all of the above are now considered during the final --check-sync for much-improved accuracy (before this change, it only compared filenames!) Many other details are explained in the included docs.
2023-12-01 08:44:38 +08:00
INFO : - Path1 Queue copy to Path2 - {path2/}file1_with white space.txt
INFO : - Path1 Queue copy to Path2 - {path2/}filename_contains_ࢺ_p1m.txt
INFO : - Path1 Queue copy to Path2 - {path2/}subdir_with_ࢺ_/file_with_測試_.txt
bisync: introduce terminal colors This introduces a few basic color codings to make the terminal output more readable (and more fun). Rclone's standard --color flag is supported. (AUTO|NEVER|ALWAYS) Only a few lines have colors right now -- more will probably be added in future versions.
2023-11-06 19:59:41 +08:00
NOTICE: - WARNING New or changed in both paths - subdir_with_ࢺ_/filechangedbothpaths_ࢺ_.txt
bisync: full support for comparing checksum, size, modtime - fixes #5679 fixes #5683 fixes #5684 fixes #5675 Before this change, bisync could only detect changes based on modtime, and would refuse to run if either path lacked modtime support. This made bisync unavailable for many of rclone's backends. Additionally, bisync did not account for the Fs's precision when comparing modtimes, meaning that they could only be reliably compared within the same side -- not against the opposite side. Size and checksum (even when available) were ignored completely for deltas. After this change, bisync now fully supports comparing based on any combination of size, modtime, and checksum, lifting the prior restriction on backends without modtime support. The comparison logic considers the backend's precision, hash types, and other features as appropriate. The comparison features optionally use a new --compare flag (which takes any combination of size,modtime,checksum) and even supports some combinations not otherwise supported in `sync` (like comparing all three at the same time.) By default (without the --compare flag), bisync inherits the same comparison options as `sync` (that is: size and modtime by default, unless modified with flags such as --checksum or --size-only.) If the --compare flag is set, it will override these defaults. If --compare includes checksum and both remotes support checksums but have no hash types in common with each other, checksums will be considered only for comparisons within the same side (to determine what has changed since the prior sync), but not for comparisons against the opposite side. If one side supports checksums and the other does not, checksums will only be considered on the side that supports them. When comparing with checksum and/or size without modtime, bisync cannot determine whether a file is newer or older -- only whether it is changed or unchanged. (If it is changed on both sides, bisync still does the standard equality-check to avoid declaring a sync conflict unless it absolutely has to.) Also included are some new flags to customize the checksum comparison behavior on backends where hashes are slow or unavailable. --no-slow-hash and --slow-hash-sync-only allow selectively ignoring checksums on backends such as local where they are slow. --download-hash allows computing them by downloading when (and only when) they're otherwise not available. Of course, this option probably won't be practical with large files, but may be a good option for syncing small-but-important files with maximum accuracy (for example, a source code repo on a crypt remote.) An additional advantage over methods like cryptcheck is that the original file is not required for comparison (for example, --download-hash can be used to bisync two different crypt remotes with different passwords.) Additionally, all of the above are now considered during the final --check-sync for much-improved accuracy (before this change, it only compared filenames!) Many other details are explained in the included docs.
2023-12-01 08:44:38 +08:00
NOTICE: - Path1 Renaming Path1 copy - {path1/}subdir_with_ࢺ_/filechangedbothpaths_ࢺ_.txt..path1
NOTICE: - Path1 Queue copy to Path2 - {path2/}subdir_with_ࢺ_/filechangedbothpaths_ࢺ_.txt..path1
bisync: introduce terminal colors This introduces a few basic color codings to make the terminal output more readable (and more fun). Rclone's standard --color flag is supported. (AUTO|NEVER|ALWAYS) Only a few lines have colors right now -- more will probably be added in future versions.
2023-11-06 19:59:41 +08:00
NOTICE: - Path2 Renaming Path2 copy - {path2/}subdir_with_ࢺ_/filechangedbothpaths_ࢺ_.txt..path2
bisync: full support for comparing checksum, size, modtime - fixes #5679 fixes #5683 fixes #5684 fixes #5675 Before this change, bisync could only detect changes based on modtime, and would refuse to run if either path lacked modtime support. This made bisync unavailable for many of rclone's backends. Additionally, bisync did not account for the Fs's precision when comparing modtimes, meaning that they could only be reliably compared within the same side -- not against the opposite side. Size and checksum (even when available) were ignored completely for deltas. After this change, bisync now fully supports comparing based on any combination of size, modtime, and checksum, lifting the prior restriction on backends without modtime support. The comparison logic considers the backend's precision, hash types, and other features as appropriate. The comparison features optionally use a new --compare flag (which takes any combination of size,modtime,checksum) and even supports some combinations not otherwise supported in `sync` (like comparing all three at the same time.) By default (without the --compare flag), bisync inherits the same comparison options as `sync` (that is: size and modtime by default, unless modified with flags such as --checksum or --size-only.) If the --compare flag is set, it will override these defaults. If --compare includes checksum and both remotes support checksums but have no hash types in common with each other, checksums will be considered only for comparisons within the same side (to determine what has changed since the prior sync), but not for comparisons against the opposite side. If one side supports checksums and the other does not, checksums will only be considered on the side that supports them. When comparing with checksum and/or size without modtime, bisync cannot determine whether a file is newer or older -- only whether it is changed or unchanged. (If it is changed on both sides, bisync still does the standard equality-check to avoid declaring a sync conflict unless it absolutely has to.) Also included are some new flags to customize the checksum comparison behavior on backends where hashes are slow or unavailable. --no-slow-hash and --slow-hash-sync-only allow selectively ignoring checksums on backends such as local where they are slow. --download-hash allows computing them by downloading when (and only when) they're otherwise not available. Of course, this option probably won't be practical with large files, but may be a good option for syncing small-but-important files with maximum accuracy (for example, a source code repo on a crypt remote.) An additional advantage over methods like cryptcheck is that the original file is not required for comparison (for example, --download-hash can be used to bisync two different crypt remotes with different passwords.) Additionally, all of the above are now considered during the final --check-sync for much-improved accuracy (before this change, it only compared filenames!) Many other details are explained in the included docs.
2023-12-01 08:44:38 +08:00
NOTICE: - Path2 Queue copy to Path1 - {path1/}subdir_with_ࢺ_/filechangedbothpaths_ࢺ_.txt..path2
INFO : - Path1 Queue copy to Path2 - {path2/}subdir_with_ࢺ_/mañana_funcionará.txt
INFO : - Path1 Queue copy to Path2 - {path2/}subdir_with_ࢺ_/test.txt
INFO : - Path2 Queue copy to Path1 - {path1/}Русский.txt
INFO : - Path2 Queue copy to Path1 - {path1/}New_top_level_mañana_funcionará.txt
INFO : - Path2 Queue copy to Path1 - {path1/}file_enconde_mañana_funcionará.txt
INFO : - Path1 Queue delete - {path1/}filename_contains_ࢺ_.txt
INFO : - Path2 Queue copy to Path1 - {path1/}subdir with␊white space.txt/file2 with␊white space.txt
INFO : - Path2 Queue copy to Path1 - "{path1/}subdir_rawchars_␙_\x81_\xfe/file3_␙_\x81_\xfe"
INFO : - Path1 Queue delete - {path1/}subdir_with_ࢺ_/filename_contains_ě_.txt
INFO : - Path2 Queue copy to Path1 - {path1/}subdir_with_ࢺ_/filename_contains_ࢺ_p2s.txt
bisync: introduce terminal colors This introduces a few basic color codings to make the terminal output more readable (and more fun). Rclone's standard --color flag is supported. (AUTO|NEVER|ALWAYS) Only a few lines have colors right now -- more will probably be added in future versions.
2023-11-06 19:59:41 +08:00
INFO : - Path2 Do queued copies to - Path1
bisync: full support for comparing checksum, size, modtime - fixes #5679 fixes #5683 fixes #5684 fixes #5675 Before this change, bisync could only detect changes based on modtime, and would refuse to run if either path lacked modtime support. This made bisync unavailable for many of rclone's backends. Additionally, bisync did not account for the Fs's precision when comparing modtimes, meaning that they could only be reliably compared within the same side -- not against the opposite side. Size and checksum (even when available) were ignored completely for deltas. After this change, bisync now fully supports comparing based on any combination of size, modtime, and checksum, lifting the prior restriction on backends without modtime support. The comparison logic considers the backend's precision, hash types, and other features as appropriate. The comparison features optionally use a new --compare flag (which takes any combination of size,modtime,checksum) and even supports some combinations not otherwise supported in `sync` (like comparing all three at the same time.) By default (without the --compare flag), bisync inherits the same comparison options as `sync` (that is: size and modtime by default, unless modified with flags such as --checksum or --size-only.) If the --compare flag is set, it will override these defaults. If --compare includes checksum and both remotes support checksums but have no hash types in common with each other, checksums will be considered only for comparisons within the same side (to determine what has changed since the prior sync), but not for comparisons against the opposite side. If one side supports checksums and the other does not, checksums will only be considered on the side that supports them. When comparing with checksum and/or size without modtime, bisync cannot determine whether a file is newer or older -- only whether it is changed or unchanged. (If it is changed on both sides, bisync still does the standard equality-check to avoid declaring a sync conflict unless it absolutely has to.) Also included are some new flags to customize the checksum comparison behavior on backends where hashes are slow or unavailable. --no-slow-hash and --slow-hash-sync-only allow selectively ignoring checksums on backends such as local where they are slow. --download-hash allows computing them by downloading when (and only when) they're otherwise not available. Of course, this option probably won't be practical with large files, but may be a good option for syncing small-but-important files with maximum accuracy (for example, a source code repo on a crypt remote.) An additional advantage over methods like cryptcheck is that the original file is not required for comparison (for example, --download-hash can be used to bisync two different crypt remotes with different passwords.) Additionally, all of the above are now considered during the final --check-sync for much-improved accuracy (before this change, it only compared filenames!) Many other details are explained in the included docs.
2023-12-01 08:44:38 +08:00
INFO : - Path1 Do queued copies to - Path2
bisync: test scenarios #5164 Co-authored-by: Chris Nelson <stuff@cjnaz.com>
2021-04-01 18:21:23 +08:00
INFO : Updating listings
INFO : Validating listings for Path1 "{path1/}" vs Path2 "{path2/}"
bisync: introduce terminal colors This introduces a few basic color codings to make the terminal output more readable (and more fun). Rclone's standard --color flag is supported. (AUTO|NEVER|ALWAYS) Only a few lines have colors right now -- more will probably be added in future versions.
2023-11-06 19:59:41 +08:00
INFO : Bisync successful
Reference in New Issue Copy Permalink