** No longer affects: rsync (Ubuntu Jammy)
** No longer affects: rsync (Ubuntu Kinetic)
** No longer affects: rsync (Ubuntu Lunar)
** Changed in: rsync (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: rsync (Ubuntu Focal)
Status: New => Confirmed
** Changed in: rsync (Ubun
** Also affects: rsync (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: rsync (Ubuntu Lunar)
Importance: Low
Status: Confirmed
** Also affects: rsync (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: rsync (Ubuntu Focal)
Importan
That's consistent with the comments above as the USB->SSD transfer
doesn't use the rsync protocol.
What we need to move this forward is a verification that applying [1] to
the version of rsync in Bionic (3.1.2) or Focal (3.1.3) fixes the issue.
If any of you affected users is available for testin
I have confirmed this bug as well. Here is what I have done:
rsync failed when transferring large files over network with error 12
when using compression (z option). rsync succeeded when I transferred
large files over USB to external SSD when using compression (z option).
rsync succeeded when tr
I just checked the behaviour when using the -zz option.
On one of my two affected systems, -zz works. However, on the other, an older
embedded system (NAS), it does not. The error message on this system is as
follows:
rsync: on remote machine: --new-compress: unknown option
rsync error: requested
Looks like there' also an openSUSE bug about this issue:
https://bugzilla.opensuse.org/show_bug.cgi?id=1175854
As I understand it the culprit is the old rsync (3.1.3). Upstream
suggests recompiling it with -with-included-zlib=yes, which I doubt
we're going to do, especially in stable releases. Th
There are a few upstream issues that seem to be related to this one, but
https://github.com/WayneD/rsync/issues/86 seems like the most likely
candidate.
Not using "-z" was determined to be a possible workaround here. If any
of you (who can actually reproduce the issue) can check if "-zz" also
wor
Since there is known workaround for this I am setting the Importance to
Low.
** Changed in: rsync (Ubuntu)
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpa
Please excuse me, it slipped my mind and I only became aware of it
through the email notification about a new activity in the bug tracker.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad
-z, really? If you could have sent an earlier post with this information, I
would have used this solution.
Maybe next time ;-)
Cheers
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net
Unfortunately, since I cannot update the target, which is an embedded
system, I have been able to help myself by disabling compression.
Instead of calling rsync with the parameters -avz I use temporarily only
-av for the affected target systems and the synchronization runs without
problems.
--
Yo
It's rsync! The new version does not like to work with the old one.
I had the same problems. After I upgraded my Ubuntu server (running VMs) from
LTS 20.04 to LTS 22.4.1. Since then the backups using rsync of the VMs (max
file size 6.2 GB) to the backup server (Debian 10) failed. Intern (within t
** Changed in: rsync (Ubuntu)
Status: Expired => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1971932
Title:
error in rsync protocol data stream
Status i
[Expired for rsync (Ubuntu) because there has been no activity for 60
days.]
** Changed in: rsync (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.lau
I attempted to reproduce by running the command through localhost over
ssh and it succeeded using a 3GB file. This may be due to the transfer
between Ubuntu and Debian then. Here is my test case:
# lxc launch images:ubuntu/jammy test-rsync
# lxc exec test-rsync bash
# apt update && apt dist-upgrad
After further reading on the subject, I guess that the problem is the
size of over 2 GB. All other thousands of files (incl. hardly further
compressible mp3, jpeg, mpeg etc.) are synchronized without problems.
Under ubuntu 20.04 LTS the problem did not occur.
--
You received this bug notification
This reminds me of bug 1384503, and a search reveals some other bugs
that may be related too. Perhaps it's a recurrence of the same
underlying issue?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bug
Well, "large" can span orders of magnitude, depending who you ask. :-)
Can you please try to identify some steps to reproduce that include the
big file generation? For example:
# 100MB file, random data (difficult to compress)
head -c 100M /dev/urandom > foo
# 100MB file, all 0s (easy to c
Thanks for your efforts and fast answer.
In the meantime I verified that it is compression related, as I read
"deflate on token returned 0 (8512 bytes left)" as an indication on
this.
Usually the action is performed using -avz parameters. When not
activating compression (-av only), the synchroniz
Hello and thanks for this bug report. I tried to reproduce this locally
but I failed. We're certainly willing to investigate this, but first we
need some steps to reproduce the problem. Could you please try to
identify a somehow reliable way to reproduce the issue and share your
findings? Thanks!
20 matches
Mail list logo
