[Freeze Exception] Please update rsync to 3.0.x for hardy

Bug #211326 reported by Bart Verwilst on 2008-04-03
8
Affects Status Importance Assigned to Milestone
backuppc (Ubuntu)
Undecided
Unassigned
rsync (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: rsync

Currently Hardy ships with rsync 2.6.9, but we were having issues with that version that are confirmed to be fixed in rsync 3.0.x. When transferring a lot of really small files, we could reliably trigger a drop in the rsync sync process, disabling us from finishing the rsync. We upgraded to rsync 3.0 and all our problems were fixed. 3.0 has an updated protocol which seems to solve this problem. Using rsync 3.0 with the old protocol forced still causes the faulty behaviour. It would be really beneficial for us at least to have the latest version of rsync available in Hardy..

Thanks!

I just want to vote for upgrading rsync to 3.0.x (3.0.1 is the newest ATM) in hardy - or at least provide it as a separate package.

Rsync 3, has a lot of improvements, including the --iconv-option which finally makes it possible to use rsync between filesystems with different character encodings.

Bart Verwilst (verwilst) on 2008-04-04
description: updated
Hanno (hzulla) wrote :

I can confirm this problem and support the request.

BackupPC is one package affected by this:

http://news.gmane.org/find-root.php?message_id=%3c47F6488A.3020602%40hanno.de%3e

On the rsync mailing lists, "rsync stalls" is a common problem reported there. The suggested fix is always "upgrade to version 3" and so I did.

After upgrading to rsync 3.0.1, the problem disappeared:

Bart Verwilst (verwilst) wrote :

I guess it's now or never for the Hardy release?..

Changed in rsync:
status: New → Incomplete
Changed in backuppc:
status: New → Invalid
Stephan Ruegamer (sadig) wrote :
Download full text (24.2 KiB)

Dear Colleagues,

please find attached the needed informations regarding a merge of new rsync 3.0.2 upstream version from debian.

A Merge would help us:

1. To get rid of the maintained CVE issue in 2.6.9-6ubuntu2 (2008-1720) it's applied upstream now
2. To help us to maintain rsync in main for a period of 5 years for security bugfixes

Changes for 3.0.2 (from upstream NEWS File...no diff included, because they are maintained as singularity)
    - Remove stop links from rc0 and rc6
      (and use update-rc.d multiuser instead of defaults)
    - maintainer field changed
    - depend on sysv-rc

Changes for 3.0.1 and 3.0.0:

NEWS for rsync 3.0.1 (3 Apr 2008)
Protocol: 30 (unchanged)
Changes since 3.0.0:

  NOTABLE CHANGES IN BEHAVIOR:

    - Added the 'c'-flag to the itemizing of non-regular files so that the
      itemized output doesn't get hidden if there were no attribute changes,
      and also so that the itemizing of a --copy-links run will distinguish
      between copying an identical non-regular file and the creation of a
      revised version with a new value (e.g. a changed symlink referent, a
      new device number, etc.).

  BUG FIXES:

    - Fixed a crash bug when a single-use rsync daemon (via remote shell) was
      run without specifying a --config=FILE option.

    - Fixed a crash when backing up a directory that has a default ACL.

    - Fixed a bug in the handling of xattr values that could cause rsync to
      not think that a file's extended attributes are up-to-date.

    - Fixed the working of --fake-super with --link-dest and --xattrs.

    - Fixed a hang when combining --dry-run with --remove-source-files.

    - Fixed a bug with --iconv's handling of files that cannot be converted:
      a failed name can no longer cause a transfer failure.

    - Fixed the building of the rounding.h file on systems that need custom
      CPPFLAGS to be used. Also improved the error reporting if the building
      of rounding.h fails.

    - Fixed the use of the --protect-args (-s) option when talking to a daemon.

    - Fixed the --ignore-existing option's protection of files on the receiver
      that are non-regular files on the sender (e.g. if a symlink or a dir on
      the sender is trying to replace a file on the receiver). The reverse
      protection (protecting a dir/symlink/device from being replaced by a
      file) was already working.

    - Fixed an assert failure if --hard-links is combined with an option that
      can skip a file in a set of hard-linked files (i.e. --ignore-existing,
      --append, etc.), without skipping all the files in the set.

    - Avoid setting the modify time on a directory that already has the right
      modify time set. This avoids tweaking the dir's ctime.

    - Improved the daemon-exclude handling to do a better job of applying the
      exclude rules to path entries. It also sends the user an error just as
      if the files were actually missing (instead of silently ignoring the
      user's args), and avoids sending the user the filter-action messages
      for these non-user-initiated rules.

    - Fixe...

Changed in rsync:
importance: Undecided → High
status: Incomplete → New
Stephan Ruegamer (sadig) wrote :
Changed in rsync:
importance: High → Wishlist
Stephan Ruegamer (sadig) wrote :

Installation log:

shermann@home-emt64:~/packages/hardy/rsync/debian$ sudo dpkg -i rsync_3.0.2-1ubuntu1_amd64.deb
(Reading database ... 323282 files and directories currently installed.)
Preparing to replace rsync 2.6.9-6ubuntu2 (using rsync_3.0.2-1ubuntu1_amd64.deb) ...
Unpacking replacement rsync ...
Setting up rsync (3.0.2-1ubuntu1) ...
Installing new version of config file /etc/init.d/rsync ...

Stephan Ruegamer (sadig) wrote :
Martin Pitt (pitti) wrote :

This is way too late for such intrusive changes in Hardy. This looks like a good candidate for a backport to hardy, once the new version is in intrepid.

Stephan Ruegamer (sadig) wrote :

Martin,

thx for the review...
so I unsubscribe release team and mark it invalid now...

\sh

Changed in rsync:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers