rsync - Jun 2004 - reporting a bug

problem with --backup

I am doing this the old fashioned way via e-mail. 

I deal with Bugzilla too much and would prefer to not open yet another bugzilla
account that generates more e-mail that I dont need to sift through, especially
when it looks very similar to in-house bugzilla stuff.

I am running rsync 2.6.2 as it is downloaded with only the --bwlimit patch
supplied by Wayne via e-mail distribution.
I running on 2 different servers that have redhat 9.1 as the OS. The command
line is:

/home/wally/rsync/rsync-2.6.2/rsync -av --rsh=rsh --backup --stats
--block-size=100000 /test/Kibbutz/Kbup_1.aaa feldor://test/Kibbutz

/home/wally is a shared mount from another redhat 9.1 system. I am moving files
from server X to server feldor.

I have a telnet session open on feldor and it is at /test/Kibbutz and I am doing
"ls -ahs" to monitor the progress of the synch.

Before the synch Kbup_1.aaa is 29Gigabytes in size. /test/Kibbutz/Kbup_1.aaa is
101 Megabytes in size.

Just prior to completion the "ls -ahs" gives me 29G Kbup_1.aaa 88M
.Kbup_1.aaa.fYAquX.
Back on X, stout has "building file list ... done
\nKbup_1.aaa\nKbup_1.aaa\n"
I do another "ls -ahs" and it gives me 29G Kbup_1.aaa~ 101M Kbup_1.aaa
72M .Kbup_1.aaa.ZizdvC

On X I get my stats and a command prompt

On feldor, I do "ls -ahs" again and get
101M Kbup_1.aaa and101M Kbup_1.aaa~

------------------

What appears to be happening is that the file renaming is happening twice and I
get 2 copies of the 101M file and loose the backup
copy of the 29G original. Note that the middle "ls -ahs" shows the 29G
file properly named but evidently there is a copy of the 101M file in process
(.Kbup_1.aaa.ZizdvC) and I suspect that it is renamed as Kbup_1.aaa and the
already completed Kbup_1.aaa is moved to
Kbup_1.aaa~ and I loose the original.

--------------------------

This has happened a couple of times, The first time was with the same command
line without the --block-size= option, and twice since with 2 different values
of the --block-size. I am pretty sure that --block-size isnt involved. I have
only started using the --backup a few hours ago so I have no idea if this always
happens or it is sensitive to what I am doing.

This may have already been reported. If so, I apologize for bringing it up
again.

wally

[I changed the subject to make it more descriptive of what is being
discussed -- it was just "reporting a bug".]

On Fri, Jun 11, 2004 at 02:31:56PM -0400, Wallace Matthews
wrote:
> What appears to be happening is that the file renaming is happening
> twice and I get 2 copies of the 101M file and loose the backup copy of
> the 29G original.
That is apparently what happens if the code decides that the file didn't
transfer correctly the first time and thus needs to be resent.  The
current code in CVS would avoid this unless --partial was specified.
I'm about to check-in a change that would also prevent a double-backup
when using --partial.

..wayne..

Hello gurus

I attemp to make a backup between two hosts, using rsync, and result is ok.

But and I agree "-e ssh" to sentence, host backup says

rsync -aurvlpogt  -e ssh kk.txt XXX.YYY.ZZZ::pruebas1
@ERROR: access denied to pruebas1 from unknown (0.0.0.0)
rsync: connection unexpectedly closed (78 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(342)

Any idea ??

Thanks...