Your message dated Tue, 11 Dec 2007 12:39:11 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#447595: rsync writes zeros to destination files on nfs 
volumes
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: rsync
Version: 2.6.9-2etch1
Severity: grave
Justification: causes non-serious data loss

At least when syncing the 2007-10-20T13:49:53 version of
security.debian.org::debian-security/dists/etch/updates/main/binary-i386/Packages.gz
on etch (2.6.9-2etch1) or sarge (2.6.4-6) to an nfs destination, rsync writes
zeroes from 4c00 to 4fff in the destination file. Local destinations work fine,
as does rsync on woody (2.5.5-0.6). Other source files haven't been tested yet.
The same applies to a self-compiled (on woody) 2.6.9 with sources from
rsync.samba.org - works on woody, fails on sarge and etch.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.23.1
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages rsync depends on:
ii  libacl1                2.2.41-1          Access control list shared library
ii  libc6                  2.3.6.ds1-13etch2 GNU C Library: Shared libraries
ii  libpopt0               1.10-3            lib for parsing cmdline parameters
ii  lsb-base               3.1-23.2etch1     Linux Standard Base 3.1 init scrip

rsync recommends no packages.

-- no debconf information



--- End Message ---
--- Begin Message ---
On Mon 22 Oct 2007, Paul Slootman wrote:
> 
> If you repeat the transfer with -vic options added, does it in fact
> report that the checksum is wrong and attempt to update?
> 
> Otherwise, a transcript of the output given by -vvvvv while it goes
> wrong would be helpful, including an strace log as well (dont' forget -f
> option to strace, as rsync forks).

As I didn't receive any feedback for almost 2 months, I'm now closing
this bug report.


Paul Slootman


--- End Message ---

Reply via email to