Bisync --max-delete behavior with --track-renames enabled #8685
Description
The associated forum post URL from https://forum.rclone.org
What is your current rclone version (output from rclone version)?
rclone version
rclone v1.70.3
os/version: debian 12.11 (64 bit)
os/kernel: 6.1.31-sun50iw9 (aarch64)
os/type: linux
os/arch: arm64 (ARMv8 compatible)
go/version: go1.24.4
go/linking: static
go/tags: none
What problem are you are trying to solve?
rclone bisync currently evaluates --max-delete before --track-renames is executed. This leads to undesirable aborts when entire directories are renamed, even though no actual deletions will occur. The core idea is that a user opting into --track-renames is explicitly signaling that renames are safe and desirable. Therefore, large apparent deletions that are later resolved by renames aren't expected by the user to trigger a safety abort, since using --track-renames is the recommended solution for renaming directories. Renamed-directories
How do you think rclone should be changed to solve that?
The --max-delete logic should be applied after --track-renames processing — i.e., only count actual unmatched entries in dstFiles that would be deleted. If not practical, bisync could instead do its own renameMap analysis before starting the sync, if there is a performance penalty for doing this, maybe this could be opt-in (e.g. --max-delete-renames-aware).
How to use GitHub
- Please use the 👍 reaction to show that you are affected by the same issue.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.