Icloud to local: corrupted on transfer: sizes differ

What is the problem you are having with rclone?

Originally icloud to crypt wrapping S3 but I was able to see it with icloud to local for easier debugging. The error messages are different with S3 but I suspect they are actually related to the errors I am seeing here with local.

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

rclone v1.69.0
- os/version: ubuntu 23.04 (64 bit)
- os/kernel: 6.2.0-39-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.23.4
- go/linking: static
- go/tags: none

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

icloud to local

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

$ rclone copy -vv icloud:"Numbers/Blank.numbers-tef" .

The rclone config contents with secrets removed.

[icloud]
type = iclouddrive
apple_id = XXX
password = XXX
cookies = XXX
trust_token = XXX

A log from the command with the -vv flag

2025/01/14 12:59:05 DEBUG : Setting --password-command "rclone-pass-store echo" from environment variable RCLONE_PASSWORD_COMMAND="rclone-pass-store echo"
2025/01/14 12:59:05 DEBUG : rclone: Version "v1.69.0" starting with parameters ["rclone" "copy" "-vv" "icloud:Numbers/Blank.numbers-tef" "."]
2025/01/14 12:59:05 DEBUG : Creating backend with remote "icloud:Numbers/Blank.numbers-tef"
2025/01/14 12:59:05 DEBUG : Using config file from "/home/jwinokur/.config/rclone/rclone.conf"
2025/01/14 12:59:05 DEBUG : icloud: Valid session, no need to reauth
2025/01/14 12:59:06 DEBUG : fs cache: renaming child cache item "icloud:Numbers/Blank.numbers-tef" to be canonical for parent "icloud:Numbers"
2025/01/14 12:59:06 DEBUG : Creating backend with remote "."
2025/01/14 12:59:06 DEBUG : fs cache: renaming cache item "." to be canonical "/home/jwinokur/hold"
2025/01/14 12:59:06 DEBUG : Blank.numbers-tef: Need to transfer - File not found at Destination
2025/01/14 12:59:09 ERROR : Blank.numbers-tef.e69878d9.partial: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /home/jwinokur/hold) 63753
2025/01/14 12:59:09 INFO  : Blank.numbers-tef.e69878d9.partial: Removing failed copy
2025/01/14 12:59:09 ERROR : Attempt 1/3 failed with 1 errors and: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /home/jwinokur/hold) 63753
2025/01/14 12:59:09 DEBUG : Blank.numbers-tef: Need to transfer - File not found at Destination
2025/01/14 12:59:11 ERROR : Blank.numbers-tef.e69878d9.partial: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /home/jwinokur/hold) 63753
2025/01/14 12:59:11 INFO  : Blank.numbers-tef.e69878d9.partial: Removing failed copy
2025/01/14 12:59:11 ERROR : Attempt 2/3 failed with 1 errors and: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /home/jwinokur/hold) 63753
2025/01/14 12:59:11 DEBUG : Blank.numbers-tef: Need to transfer - File not found at Destination
2025/01/14 12:59:13 ERROR : Blank.numbers-tef.e69878d9.partial: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /home/jwinokur/hold) 63753
2025/01/14 12:59:13 INFO  : Blank.numbers-tef.e69878d9.partial: Removing failed copy
2025/01/14 12:59:13 ERROR : Attempt 3/3 failed with 1 errors and: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /home/jwinokur/hold) 63753
2025/01/14 12:59:13 INFO  : 
Transferred:      186.776 KiB / 186.776 KiB, 100%, 20.752 KiB/s, ETA 0s
Errors:                 1 (retrying may help)
Elapsed time:         6.9s

2025/01/14 12:59:13 DEBUG : 11 go routines active
2025/01/14 12:59:13 NOTICE: Failed to copy: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /home/jwinokur/hold) 63753

Additional Information

I saw errors on 7 files:

Numbers/Blank.numbers-tef
Pages/Blank.pages
Pixelmator/Bold Bends.pxm
Pixelmator/Digital Painting.pxm
Pixelmator/Skaters.pxm
Voice Dream Library/Library/16431158-82A5-4560-9AEB-BD562C45034E/Metadata.vdrmetadata
Voice Dream Library/Library/BCDD14DC-DEF8-4106-8EFE-69F926B7B83A/Metadata.vdrmetadata

By any chance could you test the same on macOS computer?

Sure.

Macbook Pro running macOS Sonoma 14.7 (so not the latest OS but it's the best I have)

rclone v1.69.0
- os/version: darwin 14.7 (64 bit)
- os/kernel: 23.6.0 (arm64)
- os/type: darwin
- os/arch: arm64 (ARMv8 compatible)
- go/version: go1.23.4
- go/linking: dynamic
- go/tags: cmount

Then

$ rclone copy -vv icloud:"Numbers/Blank.numbers-tef" .
2025/01/14 14:55:51 DEBUG : Setting --password-command "rclone-pass-store echo" from environment variable RCLONE_PASSWORD_COMMAND="rclone-pass-store echo"
2025/01/14 14:55:51 DEBUG : rclone: Version "v1.69.0" starting with parameters ["rclone" "copy" "-vv" "icloud:Numbers/Blank.numbers-tef" "."]
2025/01/14 14:55:51 DEBUG : Creating backend with remote "icloud:Numbers/Blank.numbers-tef"
2025/01/14 14:55:51 DEBUG : Using config file from "/Users/jgwinok/.config/rclone/rclone.conf"
2025/01/14 14:55:51 DEBUG : icloud: Valid session, no need to reauth
2025/01/14 14:55:54 DEBUG : fs cache: renaming child cache item "icloud:Numbers/Blank.numbers-tef" to be canonical for parent "icloud:Numbers"
2025/01/14 14:55:54 DEBUG : Creating backend with remote "."
2025/01/14 14:55:54 DEBUG : fs cache: renaming cache item "." to be canonical "/Users/jgwinok/hold"
2025/01/14 14:55:54 DEBUG : Blank.numbers-tef: Need to transfer - File not found at Destination
2025/01/14 14:55:58 ERROR : Blank.numbers-tef.e69878d9.partial: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /Users/jgwinok/hold) 63753
2025/01/14 14:55:58 INFO  : Blank.numbers-tef.e69878d9.partial: Removing failed copy
2025/01/14 14:55:58 ERROR : Attempt 1/3 failed with 1 errors and: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /Users/jgwinok/hold) 63753
2025/01/14 14:55:59 DEBUG : Blank.numbers-tef: Need to transfer - File not found at Destination
2025/01/14 14:56:02 ERROR : Blank.numbers-tef.e69878d9.partial: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /Users/jgwinok/hold) 63753
2025/01/14 14:56:02 INFO  : Blank.numbers-tef.e69878d9.partial: Removing failed copy
2025/01/14 14:56:02 ERROR : Attempt 2/3 failed with 1 errors and: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /Users/jgwinok/hold) 63753
2025/01/14 14:56:02 DEBUG : Blank.numbers-tef: Need to transfer - File not found at Destination
2025/01/14 14:56:06 ERROR : Blank.numbers-tef.e69878d9.partial: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /Users/jgwinok/hold) 63753
2025/01/14 14:56:06 INFO  : Blank.numbers-tef.e69878d9.partial: Removing failed copy
2025/01/14 14:56:06 ERROR : Attempt 3/3 failed with 1 errors and: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /Users/jgwinok/hold) 63753
2025/01/14 14:56:06 INFO  :
Transferred:   	  186.776 KiB / 186.776 KiB, 100%, 11.320 KiB/s, ETA 0s
Errors:                 1 (retrying may help)
Elapsed time:        11.2s

2025/01/14 14:56:06 DEBUG : 12 go routines active
2025/01/14 14:56:06 NOTICE: Failed to copy: corrupted on transfer: sizes differ src(Numbers) 370168 vs dst(Local file system at /Users/jgwinok/hold) 63753
1 Like

Can you do rclone ls to find the size in iCloud of these files and compare with the size you see in the web interface?

Is there anything special about these files?

You can try --ignore-size (I think it is called)

Here is what I got:

rclone lsjson --stat icloud:"Numbers/Blank.numbers-tef"
{
        "Path": "Blank.numbers-tef",
        "Name": "Blank.numbers-tef",
        "Size": 370168,
        "MimeType": "application/octet-stream",
        "ModTime": "2013-07-25T13:19:32Z",
        "IsDir": false,
        "ID": "FILE::com.apple.CloudDocs::00000000-0000-3000-0001-000000000864"
}

So that’s the same size as seen in the log on the source. iPhone interface says 389KB which also seems wrong…

I don’t think these files are special. I thought maybe the numbers one was because it’s Apple’s format but the others aren’t.

But I honestly don’t even know what’s in them. I hardly used iCloud Drive because it lacked rclone support. Now that it does, I set it up with my normal backup system which failed. I tested manually for this post.

The other alternative to something being weird with the sizes is that the download broke silently somehow.

You could investigate this with -vv --dump bodies

This will put binary stuff in your log file so will make investigating harder but might give a clue.

I ran

$ rclone copy -vv icloud:"Numbers/Blank.numbers-tef" . --dump bodies --log-file log.log

I am hesitant to post the log publicly as it contains quite a lot of auth headers. Is there a better way to share it?

This is far from definitive, but I see six places in the log that look like binary but start with PK. Apple Numbers uses a zip-based format (like so many tools) so I extracted that chunk in a quick Python script to pull them. They are all 63330 byes (but I would take that with a grain of salt. I could be added with my rough script to pull it and/or missing the end). But even with that grain of salt, they are on the order of 63753. (Encoding as gzip wouldn't start with PK, right? It would be \x1F\x8B\x08)

The info around it is:

2025/01/15 10:07:47 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2025/01/15 10:07:47 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2025/01/15 10:07:47 DEBUG : HTTP REQUEST (req 0xc0000e2a00)
2025/01/15 10:07:47 DEBUG : GET /42425312/packageDownload?docws=<SNIP>
Host: cws.icloud-content.com:443
User-Agent: rclone/v1.69.0
Content-Type: application/json
Cookie: X-APPLE-WEBAUTH-HSA-TRUST=<SNIP>
Origin: https://www.icloud.com
Referer: https://www.icloud.com/
Accept-Encoding: gzip

2025/01/15 10:07:47 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2025/01/15 10:07:49 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2025/01/15 10:07:49 DEBUG : HTTP RESPONSE (req 0xc0000e2a00)
2025/01/15 10:07:49 DEBUG : HTTP/2.0 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://www.icloud.com
Cache-Control: no-store
Content-Disposition: attachment; filename="Blank.numbers-tef.zip"; filename*=UTF-8''Blank.numbers-tef.zip
Content-Type: application/octet-stream
Date: Wed, 15 Jan 2025 17:07:49 GMT
Server: AppleHttpServer/0235248b922d398fdf3c32958d74a46d33cfd72f
Strict-Transport-Security: max-age=31536000
X-Apple-Request-Uuid: ced9b827-fcaf-4361-9a52-47d8f3b2c70f
X-B3-Traceid: 39a82b8b21e5f61f
X-Responding-Instance: contentws:849529209:prod-p00-contentws-uscentral1a-85f7969ccb-mvzpp:8000:2429B26:nocommit

It wouldn't surprise me if this is an iCloud bug and not an rclone one but it's still too hard to tell and impacts rclone either way.

This did work to download and it is 63753 bytes but I have no way to know if it is a valid file.

I did find .numbers-tef - Apple Community which indicates that -tef means its on icloud so maybe Apple is doing something funny (kind of like OneDrive does with Office files) but pxm is not an apple format (well, they did just acquire Pixelmator).

A possible lead is that the metadata format, when downloaded with --ignore-size, is also a zip-based format (magic numbers PK).

A strong lead:

When I unzip the Blank.numbers-tef it all I get a size of 370168 Bytes!

My guess: The API is reporting to rclone the size of the accumulated files stored in a zip file but, as expected, when you download the file, which is just a zip under the hood, you get the correct zipped up file.

The question is, is this a bug in the API? How rclone interacts with the API? Both?

I will test it later by created a Numbers file and uploading it but i tmay have to wait until I am back home as I don't have iCloud Drive on my work mac.

Thanks!

Great investigation @jwink3101

OK that is interesting.

This is reminscent of the trouble we had with heic image files - the backend reports one size but the files are actually another.

Yes you are correct the magic for .zip files is "PK\x03\x04" whereas the magic for gzip files is "\x1f\x8b" as you said.

My first thought was maybe this is a content-encoding: gzip mixup, but it doesn't look like it is from that.

If you can make a nice repeatable test then you can put that into a github issue and we can ask @lostb1t to take a look (they aren't on the forum).

I will work on that.

I tried to replicate it by making a .zip of 10 highly compressible files (1 MiB of the same byte, \x00, \x01, etc) then round-tripping it to icloud and back. That worked as expected--including lsjson --stat reporting the correct size on iCloud. So I repeated it but named the file .numbers and that too worked. I can share the scripts where I did this but it's not that interesting since it worked.

I will need to test with an actual Numbers file as opposed to a fake one but alas, at work, I have more limited access.

1 Like

I have been trying to get this to happen again on a new file and I simply can't. It is 100% consistent with the given example file but whenever I try to replicate it, it works as expected.

As I said, iCloud Drive was never my main cloud storage because it didn't support rclone, so that file is likely very, very old.

My guess (hope?) is that it is a bug related to the older file on Apple's end and it is working for new files.

I think the path forward is to not worry about this further unless it comes up again. Then this will serve as another reference. Probably not worth further investment otherwise.

1 Like

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