error in rsync protocol data stream (code 12) at token.c(490) [sender=3.4.3]

[brabalan]

Since upgrading to 3.4.3 I am seeing this error running rsync -avz --delete ~/Documents/ remote_ssh:Documents:

deflate on token returned 0 (1344 bytes left)
rsync error: error in rsync protocol data stream (code 12) at token.c(490) [sender=3.4.3]

It is reproducible (it always happen at the same place).

I tried running with -vv and then rsync hangs with this:

send_files(32429, /Users/schmitta/Documents/Mastodon/.git/objects/de/b6836d9d14b010746276cb51f7bad5ebc6ce00)
send_files mapped /Users/schmitta/Documents/Mastodon/.git/objects/de/b6836d9d14b010746276cb51f7bad5ebc6ce00 of size 16451829
calling match_sums /Users/schmitta/Documents/Mastodon/.git/objects/de/b6836d9d14b010746276cb51f7bad5ebc6ce00
Mastodon/.git/objects/de/b6836d9d14b010746276cb51f7bad5ebc6ce00

It’s been running for 15 minutes now. I’ll update if it finishes with a more explicit error.

Is there a way I can help debug this?

[steadytao]

This failure is coming from the sender-side zlib token path so a few details would help narrow it down and reduce guesswork:

1. What rsync version is running on remote_ssh?
2. Does the same transfer still fail without compression?
   rsync -av --delete ~/Documents/ remote_ssh:Documents
3. Does it still fail if you force a different compression choice?
   rsync -avz --zc=zlibx --delete ~/Documents/ remote_ssh:Documents
rsync -avz --zc=zstd --delete ~/Documents/ remote_ssh:Documents
4. Could you run the failing command with negotiated-string debug enabled and paste the compression line?
   rsync -avz --debug=nstr --delete ~/Documents/ remote_ssh:Documents
5. Since it appears to stop on one Git object, does syncing only that file reproduce the same error?

Those checks should tell us whether this is specific to negotiated zlib, to one file's delta path or to the remote-side version/capability combination.

[brabalan]

Thank you for these suggestions.

1. What rsync version is running on `remote_ssh`?

I have 3.4.3 as well, but I hope it’s not picking up the old, default system one (which is 2.6.9).

2. Does the same transfer still fail without compression?
   `rsync -av --delete ~/Documents/ remote_ssh:Documents`

No, this works fine.

3. Does it still fail if you force a different compression choice?
   `rsync -avz --zc=zlibx --delete ~/Documents/ remote_ssh:Documents`

rsync: unrecognized option `--new-compress'
usage: rsync [-0468BCDEFHIKLOPRSTWVabcdghiklnopqrtuvxyz] [-e program]
  …
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(232) [sender=3.4.3]

   `rsync -avz --zc=zstd --delete ~/Documents/ remote_ssh:Documents`

rsync: unrecognized option `--compress-choice=zstd'

4. Could you run the failing command with negotiated-string debug enabled and paste the compression line?
   `rsync -avz --debug=nstr --delete ~/Documents/ remote_ssh:Documents`

5. Since it appears to stop on one Git object, does syncing only that file reproduce the same error?

Since synchronizing without compression worked, I no longer can reproduce the error (as the file has been transferred).

I’ll keep my eyes open if the error happens again to report here. I don’t know if you prefer to keep the bug open, I can very well reopen this or a new one if it happens again.

[steadytao]

I’ll keep my eyes open if the error happens again to report here.

Much appreciated.

I don’t know if you prefer to keep the bug open, I can very well reopen this or a new one if it happens again.

Haha, I am not a maintainer but I am fairly sure tridge would be happy to keep this open.

---

just my thoughts

Thank you for checking. The --zc=zlibx / --zc=zstd results make me suspect the remote side is actually running the old system rsync, not 3.4.3. The original error only reports [sender=3.4.3] which identifies the local sender. The remote errors saying --new-compress and --compress-choice=zstd are unrecognised look consistent with an older receiver being invoked over ssh.

The next thing I would check is the exact rsync binary used by ssh:
ssh remote_ssh 'command -v rsync; rsync --version | head -n 2'
If 3.4.3 is installed somewhere else on the remote, try forcing it explicitly:
rsync -avz --rsync-path=/path/to/rsync --delete ~/Documents/ remote_ssh:Documents
Then confirm with:
rsync -avz --rsync-path=/path/to/rsync --debug=nstr --delete ~/Documents/ remote_ssh:Documents

If the failure only happened with the older remote binary this may be a mixed-version compression interaction rather than a pure 3.4.3-to-3.4.3 bug. If it happens again with the remote definitely running 3.4.3 then the --debug=nstr compression line and a single-file reproducer would be the most useful next details (if possible).

[brabalan]

So it seems I was running the old version on the other machine. I updated my scripts. Thanks a lot for the suggestion!