operations.Move accounts a transfer on fallback to server-side Copy #8799
Description
The associated forum post URL from https://forum.rclone.org
What is the problem you are having with rclone?
operations.Move (per its function comment) is supposed to be only accounted as a check. But on backends like S3 which can Copy but not Move, the move falls back to server-side copy and ends up getting counted as a transfer anyway, even when isTransfer == false.
rclone/fs/operations/operations.go
Lines 413 to 416 in 99e8a63
rclone/fs/operations/operations.go
Line 506 in 99e8a63
Line 381 in 99e8a63
This could theoretically be fixed by making a similar Copy / CopyTransfer scheme and/or passing an isTransfer param to Copy.
See the 68a9019 commit message for further explanation about why this affects chunker differently from other backends.
This was discovered (but not fixed) on #8796.
What is your rclone version (output from rclone version)
rclone v1.72.0-DEV
- os/version: darwin 14.7.2 (64 bit)
- os/kernel: 23.6.0 (arm64)
- os/type: darwin
- os/arch: arm64 (ARMv8 compatible)
- go/version: go1.25.0
- go/linking: dynamic
- go/tags: none
Which OS you are using and how many bits (e.g. Windows 7, 64 bit)
macOS Sonoma 14.7.2 (64 bit)
Which cloud storage system are you using? (e.g. Google Drive)
Can reproduce this on TestChunkerS3: (chunker wrapping s3)
The command you were trying to run (e.g. rclone copy /tmp remote:tmp)
go test ./cmd/bisync -remote TestChunkerS3: -case all_changed -v
(note: must revert d915f75 to reproduce the error)
A log from the command with the -vv flag (e.g. output from rclone -vv copy /tmp remote:tmp)
https://pub.rclone.org/integration-tests/2025-09-03-010013/chunker-cmd.bisync-TestChunkerS3-5.txt
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.