4 Commits

Include renames

Author	SHA1	Message	Date
f-denkena	b957d264df	bisync: hard file/byte delete caps and dual-boot session-name ... --max-delete-files and --max-delete-size are independent of the percent cap. --session-name shares listings/locks across OS path strings.	2026-09-10 01:03:08 +02:00
nielash	199d82969b	bisync: normalize session name to non-canonical - fixes #7423 ... Before this change, bisync used the "canonical" Fs name in the filename for its listing files, including any {hexstring} suffix. An unintended consequence of this was that if a user added a backend-specific flag from the command line (thus "overriding" the config), bisync would fail to find the listing files it created during the prior run without this flag, due to the path now having a {hexstring} suffix that wasn't there before (or vice versa, if the flag was present when the session was established, and later removed.) This would sometimes cause bisync to fail with a critical error (if no listing existed with the alternate name), or worse -- it would sometimes cause bisync to use an old, incorrect listing (if old listings with the alternate name DID still exist, from before the user changed their flags.) After this change, the issue is fixed by always normalizing the SessionName to the non-canonical version (no {hexstring} suffix), regardless of the flags. To avoid a breaking change, we first check if a suffixed listing exists. If so, we rename it (and overwrite the non-suffixed version, if any.) If not, we carry on with the non-suffixed version. (We should only find a suffixed version if created prior to this commit.) The result for the user is that the same pair of paths will always use the same .lst filenames, with or without backend-specific flags.	2024-01-20 15:38:26 -05:00
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
Ivan AndreevandChris Nelson	6210e22ab5	bisync: implementation #5164 ... Fixes #118 Co-authored-by: Chris Nelson <stuff@cjnaz.com>	2021-11-01 21:00:27 +03:00