I have a simple backup shell script that I am using for backups.
I have a problem which I think is a result of this error:
rsync warning: some files vanished before they could be transferred (code
24) at main.c(789)
Any command after the rsync never gets executed if I get the above error.
The
https://bugzilla.samba.org/show_bug.cgi?id=3392
--- Comment #2 from [EMAIL PROTECTED] 2006-01-10 17:22 MST ---
Created an attachment (id=1661)
--> (https://bugzilla.samba.org/attachment.cgi?id=1661&action=view)
main.c from my custom rsync, showing rewritten get_local_name
--
Confi
https://bugzilla.samba.org/show_bug.cgi?id=3392
--- Comment #1 from [EMAIL PROTECTED] 2006-01-10 17:22 MST ---
This behavior is a consequence of the strange logic in get_local_name in
main.c. If the destination path is given as a file, then rsync uses a "local
name" and accesses the
On Tue, Jan 10, 2006 at 11:31:08PM +0100, Ren? Rebe wrote:
> Also I found the current code does decide from the receiving-side file
> what blocksize to use.
The idea here is that the only checksum data that get transmitted and
stored in the hash table are those for the blocks in the file on the
re
Hi,
On Tuesday 10 January 2006 21:47, Wayne Davison wrote:
> On Tue, Jan 10, 2006 at 09:02:14PM +0100, Ren? Rebe wrote:
> > So far just increasing the block-size significantly (10-20MB) bumps
> > the speed by magnitudes into useful regions.
>
> That's good. For some reason I was thinking that th
On Tue, Jan 10, 2006 at 09:02:14PM +0100, Ren? Rebe wrote:
> So far just increasing the block-size significantly (10-20MB) bumps
> the speed by magnitudes into useful regions.
That's good. For some reason I was thinking that the block size was
nearly maxxed out for a 50GB file, but I can see that
Hi Wayne,
On Tuesday 10 January 2006 20:29, you wrote:
> On Tue, Jan 10, 2006 at 07:46:19PM +0100, Ren? Rebe wrote:
> > of course the dual cpu ppc64 receiver is idling waiting for any data
> > to arrive.
>
> There is a known problem with really large numbers of blocks: the hash
> search algorithm
On Tue, Jan 10, 2006 at 07:46:19PM +0100, Ren? Rebe wrote:
> of course the dual cpu ppc64 receiver is idling waiting for any data
> to arrive.
There is a known problem with really large numbers of blocks: the hash
search algorithm gets too many collisions, and the search routine bogs
down. This s
Hi,
in reply to my previous post, I can reproduce the issue locally here.
I produced a 50146750688 bytes /home/test.dat out of cat'ing a lot of data
files together (needed some input data ...). The initial rsync take over an hour
saturating the 100mbit ethernet. I then used shred on the first GB
https://bugzilla.samba.org/show_bug.cgi?id=3392
Summary: fuzzy misbehaving if source is a file
Product: rsync
Version: 2.6.6
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P3
Compone
Can I disable socket, only enable ssh tunnel ?
Thanks for some help
Cauchy
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
A vanilla RHEL3 install or a RHEL3 install with a vanilla kernel?
Just making sure here...
--Gian
On Sat, Jan 07, 2006 at 10:22:57AM -0500, Tim Boyer wrote:
It's not many files, but since I'm running as root, I'm curious why
there's a problem creating/deleting/unlinking these files.
Thomas D. Harrison wrote:
Madison,
That sounds like a really nice backup program. I'd like to try your
Beta out if I could. I've use rsync regularly and it would be great to
have a front end.
Thanks.
Thom
W00ts. :)
You can download the latest version from http://tle-bu.org. Please
Madison,
That sounds like a really nice backup program. I'd like to try your
Beta out if I could. I've use rsync regularly and it would be great
to have a front end.
Thanks.
Thom
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: htt
14 matches
Mail list logo
