What is the problem you are having with rclone?
rclone copies unchanged files.
This happens on a local pCloud drive (directory) which I use as an encrypted remote via rclone.
See [lpc-crypt] in the configs below.
This does not happen with a local directory which I use as an encrypted remote via rclone.
See [local-crypt] in the configs below.
Remark: Currently I trying to encrypt the data to the local pCloud drive, because doing it remotely directly to pCloud does not work at the moment. But this is another story, I cannot create the necessary app under pCloud (Temporary unavailable, please contact support team.) Here I will contact the pCloud support because of this.
Run the command 'rclone version' and share the full output of the command.
tom@bobby:~/tmp$ rclone version
rclone v1.68.2
- os/version: ubuntu 22.04 (64 bit)
- os/kernel: 6.8.0-50-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.23.3
- go/linking: static
- go/tags: none
Remark: I first tested it with rclone v1.53.3-DEV which is part of my Ubuntu installation. Here I have the same problem, so I decided to make the rest of the tests with the newest rclone version.
Which cloud storage system are you using? (eg Google Drive)
A local pcloud drive, see:
tom@bobby:~/tmp$ df -hT | grep fuse
pCloud.fs fuse 4,0G 89M 4,0G 3% /home/tom/pCloudDrive
The command you were trying to run (eg rclone copy /tmp remote:tmp)
tom@bobby:~/tmp$ rclone lsl lpc-crypt:
tom@bobby:~/tmp$ rclone copy -P v.jpg lpc-crypt:
Transferred: 108.473 KiB / 108.473 KiB, 100%, 0 B/s, ETA -
Transferred: 1 / 1, 100%
Elapsed time: 0.0s
tom@bobby:~/tmp$ rclone lsl lpc-crypt:
111012 2020-11-23 00:45:28.000000000 v.jpg
tom@bobby:~/tmp$ rclone copy -P v.jpg lpc-crypt:
Transferred: 108.473 KiB / 108.473 KiB, 100%, 0 B/s, ETA -
Transferred: 1 / 1, 100%
Elapsed time: 0.0s
tom@bobby:~/tmp$ rclone lsl lpc-crypt:
111012 2020-11-23 00:45:28.000000000 v.jpg
I used -P so that you can see that the file is transferred also the second time. I started from the beginning with an empty directory so that you can easily see what happens.
Workarounds using -local-no-set-modtime or --checksum:
tom@bobby:~/tmp$ rclone copy -P --local-no-set-modtime v.jpg lpc-crypt:
Transferred: 0 B / 0 B, -, 0 B/s, ETA -
Elapsed time: 0.0s
tom@bobby:~/tmp$ rclone copy -P --checksum v.jpg lpc-crypt:
2025/01/03 17:22:11 NOTICE: Encrypted drive 'lpc-crypt:': --checksum is in use but the source and destination have no hashes in common; falling back to --size-only
Transferred: 0 B / 0 B, -, 0 B/s, ETA -
Elapsed time: 0.0s
I was surprised that they have no hashes in common but what rclone shows me here is consistent:
tom@bobby:~/tmp$ rclone backend features lpc-crypt: | grep Hashes
"Hashes": [],
Remark: If I use local-crypt instead of lpc-crypt (see configs below) this does not happen. This means the file is not transfered if it is unchanged. BTW also this other encrypted remote does not have hashes.
tom@bobby:~/tmp$ rclone backend features local-crypt: | grep Hashes
"Hashes": [],
Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.
tom@bobby:~/tmp$ rclone config redacted
[local-crypt]
type = crypt
remote = lpcloud:/home/tom/TestMeCrypt
directory_name_encryption = true
password = XXX
password2 = XXX
[lpc-crypt]
type = crypt
remote = lpcloud:/home/tom/pCloudDrive/TestMeCrypt
directory_name_encryption = true
password = XXX
password2 = XXX
[lpcloud]
type = local
### Double check the config for sensitive info before posting publicly
A log from the command that you were trying to run with the -vv flag
tom@bobby:~/tmp$ rclone copy -vv v.jpg lpc-crypt:
2025/01/03 17:30:52 DEBUG : rclone: Version "v1.68.2" starting with parameters ["rclone" "copy" "-vv" "v.jpg" "lpc-crypt:"]
2025/01/03 17:30:52 DEBUG : Creating backend with remote "v.jpg"
2025/01/03 17:30:52 DEBUG : Using config file from "/home/tom/.config/rclone/rclone.conf"
2025/01/03 17:30:52 DEBUG : fs cache: adding new entry for parent of "v.jpg", "/home/tom/tmp"
2025/01/03 17:30:52 DEBUG : Creating backend with remote "lpc-crypt:"
2025/01/03 17:30:52 DEBUG : Creating backend with remote "lpcloud:/home/tom/pCloudDrive/TestMeCrypt"
2025/01/03 17:30:52 DEBUG : v.jpg: Modification times differ by -781.188895ms: 2020-11-23 00:45:28.781188895 +0100 CET, 2020-11-23 00:45:28 +0100 CET
2025/01/03 17:30:52 DEBUG : preAllocate: got error on fallocate, trying combination 1/2: operation not supported
2025/01/03 17:30:52 DEBUG : preAllocate: got error on fallocate, trying combination 2/2: operation not supported
2025/01/03 17:30:52 DEBUG : v.jpg.3e35d94b.partial: md5 = a9f7fcb7d5c5e080e3c5ae26d421eeb8 OK
2025/01/03 17:30:52 DEBUG : v.jpg.3e35d94b.partial: renamed to: v.jpg
2025/01/03 17:30:52 INFO : v.jpg: Copied (replaced existing)
2025/01/03 17:30:52 INFO :
Transferred: 108.473 KiB / 108.473 KiB, 100%, 0 B/s, ETA -
Transferred: 1 / 1, 100%
Elapsed time: 0.0s
2025/01/03 17:30:52 DEBUG : 7 go routines active
tom@bobby:~/tmp$
So my question here is. Is this the expected behavior using a locally mounted pCloud drive and I have to use the workarounds, here especially --local-no-set-modtime?
Or is it a bug? From the debug output it seems to be the case, that it is copied because the modifications times differ.
