extern/rclone
1
0
Fork 0
mirror of https://github.com/rclone/rclone.git synced 2024-12-12 02:02:02 +01:00
Code Issues Packages Projects Releases Wiki Activity
8d3bcc025a
rclone/cmd/bisync/testdata/test_backupdir/golden/test.log

154 lines
8.3 KiB
Plaintext
Raw Normal View History

bisync: add overlapping paths check Before this change, Bisync did not check to make sure that Path1 and Path2 do not overlap, nor did it check for overlaps with `--backup-dir`. While `sync` does check for these things, it can sometimes be fooled because of the way Bisync calls it with `--files-from` filters. Relying on sync could also leave a run in a half-finished state if it were to error in one direction but not the other (`--backup-dir` only checks for overlaps with the dest.) After this change, Bisync does its own check up front, so we can quickly return an error and exit before any changes are made.
2023-12-18 19:03:14 +01:00
(01) : test backupdir
(02) : test initial bisync
(03) : bisync resync backupdir1={workdir/}backupdirs/backupdir1 backupdir2={workdir/}backupdirs/backupdir2
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
}
INFO : Synching Path1 "{path1/}" with Path2 "{path2/}"
INFO : Copying unique Path2 files to Path1
INFO : - Path2 Resync is copying UNIQUE files to - Path1
INFO : - Path1 Resync is copying UNIQUE OR DIFFERING files to - Path2
INFO : Resync updating listings
INFO : Bisync successful
(04) : test make modifications on both paths
(05) : test new on path2 - file10
(06) : touch-copy 2001-01-02 {datadir/}file10.txt {path2/}
(07) : test newer on path2 - file1
(08) : touch-copy 2001-01-02 {datadir/}file1.txt {path2/}
(09) : test new on path1 - file11
(10) : touch-copy 2001-01-02 {datadir/}file11.txt {path1/}
(11) : test newer on path1 - file2
(12) : touch-copy 2001-01-02 {datadir/}file2.txt {path1/}
(13) : test deleted on path2 - file3
(14) : delete-file {path2/}file3.txt
(15) : test deleted on path1 - file4
(16) : delete-file {path1/}file4.txt
(17) : test deleted on both paths - file8
(18) : delete-file {path1/}file8.txt
(19) : delete-file {path2/}file8.txt
(20) : test changed on both paths - file5 (file5R, file5L)
(21) : touch-glob 2001-01-02 {datadir/} file5R.txt
(22) : copy-as {datadir/}file5R.txt {path2/} file5.txt
(23) : touch-glob 2001-03-04 {datadir/} file5L.txt
(24) : copy-as {datadir/}file5L.txt {path1/} file5.txt
(25) : test newer on path2 and deleted on path1 - file6
(26) : touch-copy 2001-01-02 {datadir/}file6.txt {path2/}
(27) : delete-file {path1/}file6.txt
(28) : test newer on path1 and deleted on path2 - file7
(29) : touch-copy 2001-01-02 {datadir/}file7.txt {path1/}
(30) : delete-file {path2/}file7.txt
(31) : test bisync run
(32) : bisync backupdir1={workdir/}backupdirs/backupdir1 backupdir2={workdir/}backupdirs/backupdir2
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
}
INFO : Synching Path1 "{path1/}" with Path2 "{path2/}"
INFO : Building Path1 and Path2 listings
INFO : Path1 checking for diffs
INFO : - Path1 File changed: size (larger), time (newer) - file2.txt
INFO : - Path1 File was deleted - file4.txt
INFO : - Path1 File changed: size (larger), time (newer) - file5.txt
INFO : - Path1 File was deleted - file6.txt
INFO : - Path1 File changed: size (larger), time (newer) - file7.txt
INFO : - Path1 File was deleted - file8.txt
INFO : - Path1 File is new - file11.txt
INFO : Path1: 7 changes:  1 new,  3 modified,  3 deleted
INFO : (Modified:  3 newer,  0 older,  3 larger,  0 smaller)
INFO : Path2 checking for diffs
INFO : - Path2 File changed: size (larger), time (newer) - file1.txt
INFO : - Path2 File was deleted - file3.txt
INFO : - Path2 File changed: size (larger), time (newer) - file5.txt
INFO : - Path2 File changed: size (larger), time (newer) - file6.txt
INFO : - Path2 File was deleted - file7.txt
INFO : - Path2 File was deleted - file8.txt
INFO : - Path2 File is new - file10.txt
INFO : Path2: 7 changes:  1 new,  3 modified,  3 deleted
INFO : (Modified:  3 newer,  0 older,  3 larger,  0 smaller)
INFO : Applying changes
INFO : Checking potential conflicts...
ERROR : file5.txt: md5 differ
NOTICE: {path2String}: 1 differences found
NOTICE: {path2String}: 1 errors while checking
INFO : Finished checking the potential conflicts. 1 differences found
INFO : - Path1 Queue copy to Path2 - {path2/}file11.txt
INFO : - Path1 Queue copy to Path2 - {path2/}file2.txt
INFO : - Path2 Queue delete - {path2/}file4.txt
NOTICE: - WARNING New or changed in both paths - file5.txt
bisync: add options to auto-resolve conflicts - fixes #7471 Before this change, when a file was new/changed on both paths (relative to the prior sync), and the versions on each side were not identical, bisync would keep both versions, renaming them with ..path1 and ..path2 suffixes, respectively. Many users have requested more control over how bisync handles such conflicts -- including an option to automatically select one version as the "winner" and rename or delete the "loser". This change introduces support for such options. --conflict-resolve CHOICE In bisync, a "conflict" is a file that is *new* or *changed* on *both sides* (relative to the prior run) AND is *not currently identical* on both sides. `--conflict-resolve` controls how bisync handles such a scenario. The currently supported options are: - `none` - (the default) - do not attempt to pick a winner, keep and rename both files according to `--conflict-loser` and `--conflict-suffix` settings. For example, with the default settings, `file.txt` on Path1 is renamed `file.txt.conflict1` and `file.txt` on Path2 is renamed `file.txt.conflict2`. Both are copied to the opposite path during the run, so both sides end up with a copy of both files. (As `none` is the default, it is not necessary to specify `--conflict-resolve none` -- you can just omit the flag.) - `newer` - the newer file (by `modtime`) is considered the winner and is copied without renaming. The older file (the "loser") is handled according to `--conflict-loser` and `--conflict-suffix` settings (either renamed or deleted.) For example, if `file.txt` on Path1 is newer than `file.txt` on Path2, the result on both sides (with other default settings) will be `file.txt` (winner from Path1) and `file.txt.conflict1` (loser from Path2). - `older` - same as `newer`, except the older file is considered the winner, and the newer file is considered the loser. - `larger` - the larger file (by `size`) is considered the winner (regardless of `modtime`, if any). - `smaller` - the smaller file (by `size`) is considered the winner (regardless of `modtime`, if any). - `path1` - the version from Path1 is unconditionally considered the winner (regardless of `modtime` and `size`, if any). This can be useful if one side is usually more trusted or up-to-date than the other. - `path2` - same as `path1`, except the path2 version is considered the winner. For all of the above options, note the following: - If either of the underlying remotes lacks support for the chosen method, it will be ignored and fall back to `none`. (For example, if `--conflict-resolve newer` is set, but one of the paths uses a remote that doesn't support `modtime`.) - If a winner can't be determined because the chosen method's attribute is missing or equal, it will be ignored and fall back to `none`. (For example, if `--conflict-resolve newer` is set, but the Path1 and Path2 modtimes are identical, even if the sizes may differ.) - If the file's content is currently identical on both sides, it is not considered a "conflict", even if new or changed on both sides since the prior sync. (For example, if you made a change on one side and then synced it to the other side by other means.) Therefore, none of the conflict resolution flags apply in this scenario. - The conflict resolution flags do not apply during a `--resync`, as there is no "prior run" to speak of (but see `--resync-mode` for similar options.) --conflict-loser CHOICE `--conflict-loser` determines what happens to the "loser" of a sync conflict (when `--conflict-resolve` determines a winner) or to both files (when there is no winner.) The currently supported options are: - `num` - (the default) - auto-number the conflicts by automatically appending the next available number to the `--conflict-suffix`, in chronological order. For example, with the default settings, the first conflict for `file.txt` will be renamed `file.txt.conflict1`. If `file.txt.conflict1` already exists, `file.txt.conflict2` will be used instead (etc., up to a maximum of 9223372036854775807 conflicts.) - `pathname` - rename the conflicts according to which side they came from, which was the default behavior prior to `v1.66`. For example, with `--conflict-suffix path`, `file.txt` from Path1 will be renamed `file.txt.path1`, and `file.txt` from Path2 will be renamed `file.txt.path2`. If two non-identical suffixes are provided (ex. `--conflict-suffix cloud,local`), the trailing digit is omitted. Importantly, note that with `pathname`, there is no auto-numbering beyond `2`, so if `file.txt.path2` somehow already exists, it will be overwritten. Using a dynamic date variable in your `--conflict-suffix` (see below) is one possible way to avoid this. Note also that conflicts-of-conflicts are possible, if the original conflict is not manually resolved -- for example, if for some reason you edited `file.txt.path1` on both sides, and those edits were different, the result would be `file.txt.path1.path1` and `file.txt.path1.path2` (in addition to `file.txt.path2`.) - `delete` - keep the winner only and delete the loser, instead of renaming it. If a winner cannot be determined (see `--conflict-resolve` for details on how this could happen), `delete` is ignored and the default `num` is used instead (i.e. both versions are kept and renamed, and neither is deleted.) `delete` is inherently the most destructive option, so use it only with care. For all of the above options, note that if a winner cannot be determined (see `--conflict-resolve` for details on how this could happen), or if `--conflict-resolve` is not in use, *both* files will be renamed. --conflict-suffix STRING[,STRING] `--conflict-suffix` controls the suffix that is appended when bisync renames a `--conflict-loser` (default: `conflict`). `--conflict-suffix` will accept either one string or two comma-separated strings to assign different suffixes to Path1 vs. Path2. This may be helpful later in identifying the source of the conflict. (For example, `--conflict-suffix dropboxconflict,laptopconflict`) With `--conflict-loser num`, a number is always appended to the suffix. With `--conflict-loser pathname`, a number is appended only when one suffix is specified (or when two identical suffixes are specified.) i.e. with `--conflict-loser pathname`, all of the following would produce exactly the same result: ``` --conflict-suffix path --conflict-suffix path,path --conflict-suffix path1,path2 ``` Suffixes may be as short as 1 character. By default, the suffix is appended after any other extensions (ex. `file.jpg.conflict1`), however, this can be changed with the `--suffix-keep-extension` flag (i.e. to instead result in `file.conflict1.jpg`). `--conflict-suffix` supports several *dynamic date variables* when enclosed in curly braces as globs. This can be helpful to track the date and/or time that each conflict was handled by bisync. For example: ``` --conflict-suffix {DateOnly}-conflict // result: myfile.txt.2006-01-02-conflict1 ``` All of the formats described [here](https://pkg.go.dev/time#pkg-constants) and [here](https://pkg.go.dev/time#example-Time.Format) are supported, but take care to ensure that your chosen format does not use any characters that are illegal on your remotes (for example, macOS does not allow colons in filenames, and slashes are also best avoided as they are often interpreted as directory separators.) To address this particular issue, an additional `{MacFriendlyTime}` (or just `{mac}`) option is supported, which results in `2006-01-02 0304PM`. Note that `--conflict-suffix` is entirely separate from rclone's main `--sufix` flag. This is intentional, as users may wish to use both flags simultaneously, if also using `--backup-dir`. Finally, note that the default in bisync prior to `v1.66` was to rename conflicts with `..path1` and `..path2` (with two periods, and `path` instead of `conflict`.) Bisync now defaults to a single dot instead of a double dot, but additional dots can be added by including them in the specified suffix string. For example, for behavior equivalent to the previous default, use: ``` [--conflict-resolve none] --conflict-loser pathname --conflict-suffix .path ```
2023-12-15 13:47:15 +01:00
NOTICE: - Path1 Renaming Path1 copy - {path1/}file5.txt.conflict1
NOTICE: - Path1 Queue copy to Path2 - {path2/}file5.txt.conflict1
NOTICE: - Path2 Renaming Path2 copy - {path2/}file5.txt.conflict2
NOTICE: - Path2 Queue copy to Path1 - {path1/}file5.txt.conflict2
bisync: add overlapping paths check Before this change, Bisync did not check to make sure that Path1 and Path2 do not overlap, nor did it check for overlaps with `--backup-dir`. While `sync` does check for these things, it can sometimes be fooled because of the way Bisync calls it with `--files-from` filters. Relying on sync could also leave a run in a half-finished state if it were to error in one direction but not the other (`--backup-dir` only checks for overlaps with the dest.) After this change, Bisync does its own check up front, so we can quickly return an error and exit before any changes are made.
2023-12-18 19:03:14 +01:00
INFO : - Path2 Queue copy to Path1 - {path1/}file6.txt
INFO : - Path1 Queue copy to Path2 - {path2/}file7.txt
INFO : - Path2 Queue copy to Path1 - {path1/}file1.txt
INFO : - Path2 Queue copy to Path1 - {path1/}file10.txt
INFO : - Path1 Queue delete - {path1/}file3.txt
INFO : - Path2 Do queued copies to - Path1
INFO : - Path1 Do queued copies to - Path2
INFO : Updating listings
INFO : Validating listings for Path1 "{path1/}" vs Path2 "{path2/}"
INFO : Bisync successful
(33) : bisync backupdir1={workdir/}backupdirs/backupdir1 backupdir2={workdir/}backupdirs/backupdir2
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
}
INFO : Synching Path1 "{path1/}" with Path2 "{path2/}"
INFO : Building Path1 and Path2 listings
INFO : Path1 checking for diffs
INFO : Path2 checking for diffs
INFO : No changes found
INFO : Updating listings
INFO : Validating listings for Path1 "{path1/}" vs Path2 "{path2/}"
INFO : Bisync successful
(34) : test overlapping path -- should fail
(35) : bisync backupdir1={path1/}subdir/backupdir1 backupdir2={path2/}subdir/backupdir2
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
}
INFO : Synching Path1 "{path1/}" with Path2 "{path2/}"
ERROR : Bisync critical error: destination and parameter to --backup-dir mustn't overlap
ERROR : Bisync aborted. Must run --resync to recover.
Bisync error: bisync aborted
Reference in New Issue Copy Permalink