Rclone sync copying files twice (dry-run)

What is the problem you are having with rclone?

rclone is logging the copy of a file twice during a single dry-run sync. This happens for many files in my sync. Is this expected behavior?

I haven't yet verified whether this happens for an actual sync (the log file is already 500MB when this happens).

Run the command 'rclone version' and share the full output of the command.

rclone 1.61.1

  • os/version: darwin 12.6.3 (64 bit)
  • os/kernel: 21.6.0 (arm64)
  • os/type: darwin
  • os/arch: arm64
  • go/version: go1.19.5
  • go/linking: dynamic
  • go/tags: cmount

Which cloud storage system are you using? (eg Google Drive)


The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone sync --use-json-log --fast-list --links --track-renames --track-renames-strategy modtime,leaf --bwlimit 400K --dry-run --progress /var/folders/t3/n6h1s2ss58n5l5llnt6c4zbh0000gn/T/tmpftm4wpug/Users/brechtm crypt:Backup/MacBook/Users/brechtm/latest

(I'm cloning from an APFS snapshot mounted at that temporary directory)

The rclone config contents with secrets removed.

type = pcloud
hostname = eapi.pcloud.com
token = ...

type = crypt
remote = pcloud:.crypt
filename_encryption = standard
directory_name_encryption = true
password = ...
password2 = ...

A log from the command with the -vv flag

Since the entire log is huge, here are the two log messages for a specific file path. Note that they occur more than a minute apart.

{"level":"warning","msg":"Skipped copy as --dry-run is set (size 22)","object":".pyenv/versions/3.11.1/openssl/share/doc/openssl/html/man3/EVP_PKEY_get0_engine.html.rclonelink","objectType":"*local.Object","size":22,"skipped":"copy","source":"operations/operations.go:2358","time":"2023-03-24T12:43:48.675595+01:00"}
{"level":"warning","msg":"Skipped copy as --dry-run is set (size 22)","object":".pyenv/versions/3.11.1/openssl/share/doc/openssl/html/man3/EVP_PKEY_get0_engine.html.rclonelink","objectType":"*local.Object","size":22,"skipped":"copy","source":"operations/operations.go:2358","time":"2023-03-24T12:45:02.175139+01:00"}

I suspect there was a high level retry in there to clear up errors.

You should be able to see this in the log.

It is controlled by the --retries flag

Thanks, Nick. That was it, indeed!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.