Bisync --max-delete behavior with --track-renames enabled #8685

The associated forum post URL from https://forum.rclone.org

https://forum.rclone.org/t/bisync-max-delete-behavior-conflicts-with-track-renames-during-directory-renames/51944

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.