Re: [PATCH] Batch-mode rewrite

On Thu, Jul 22, 2004 at 07:01:12PM -0400, Chris Shoemaker wrote: > On Thu, Jul 22, 2004 at 06:36:27PM -0700, Wayne Davison wrote: > > And don't forget the hard-link post-processing -- it would also need to > > happen after the receiver finished its job. > > Ok, it's late and this new patch seems l

Re: [PATCH] Batch-mode rewrite

On Thu, Jul 22, 2004 at 06:36:27PM -0700, Wayne Davison wrote: > On Wed, Jul 21, 2004 at 03:54:11PM -0400, Chris Shoemaker wrote: > > What data exactly? I thought: > > 1) all recv-to-gen communications went through the error_pipe[] fds. > > Yes, that became true when I got rid of the extra pi

Re: Rsync Performance

On Thu, Jul 22, 2004 at 07:33:21PM -0700, Wayne Davison wrote: > On Fri, Jul 23, 2004 at 02:15:04PM +1200, Jason Haar wrote: > > is there any intention of a "new improved" "--partial" option whereby > > any failed uploads are kept as temp files > > I had been contemplating whether we need a new op

Re: Rsync Performance

On Fri, Jul 23, 2004 at 02:15:04PM +1200, Jason Haar wrote: > is there any intention of a "new improved" "--partial" option whereby > any failed uploads are kept as temp files I had been contemplating whether we need a new option for this or not. One idea would be to change the behavior when --par

Re: [PATCH] Batch-mode rewrite

On Thu, Jul 22, 2004 at 04:10:41PM -0400, Chris Shoemaker wrote: > I took a crack a batch-mode test case, to try avoid batch-mode > regressions. Does this look reasonable? Yes, that looks good. I made some minor changes and checked it in. > Also, I came across a confusing typo (I think.) Also

Re: Rsync Performance

On Wed, Jul 21, 2004 at 02:30:04PM -0700, Wayne Davison wrote: > That's what the --partial option indicates, though it does move the > partial file into place awaiting the next transfer (it does not auto- > resume). ..and would crash the box if that was an OS file... This has been discussed befor

Re: [PATCH] Batch-mode rewrite

On Wed, Jul 21, 2004 at 03:54:11PM -0400, Chris Shoemaker wrote: > What data exactly? I thought: > 1) all recv-to-gen communications went through the error_pipe[] fds. Yes, that became true when I got rid of the extra pipe that used to separate the redo values from the error messages. >

Re: [PATCH] Batch-mode rewrite

Wayne, I took a crack a batch-mode test case, to try avoid batch-mode regressions. Does this look reasonable? Also, I came across a confusing typo (I think.) Also attached. -chris Index: testsuite/README.testsuite === RCS file: /

Re: HP-UX 11i and largefiles on rsync 2.6.2

On Thu, Jul 22, 2004 at 04:27:57PM -0400, Don Malloy wrote: > server2 # ./rsync -a --progress --stats file1.db /var/opt/ignite What I want is the backtrace when the rsync that is failing dies so we can (hopefully) figure out why it is dying. In the above command the client should be the sender,

ERROR: out of memory in receive_file_entry

Hello, I'm looking for some possible solutions to the out of memory problem when dealing with very large directory trees. Client: linux-2.4.20 Server: HP-UX 11.11 rsync version: 2.6.2 Directory size: 400Gbytes number of files: 3273133 rsync cmd: rsync -avRx --progress --stats --numeric-ids -

Re: HP-UX 11i and largefiles on rsync 2.6.2

I started rsync as follows: server2 # ./rsync -a --progress --stats file1.db /var/opt/ignite building file list ... 1 file to consider file1.db 1951039488 45%4.40MB/s0:08:420:14:56 rsync: writefd_unbuffered failed to write 32768 bytes: phase "unknown": Broken pipe (32) rsync error: error

Re: Strange behaviour rsync pull from sun to ppc linux, Integer overflow - attempted 64 bit offset

On Thu, Jul 22, 2004 at 07:09:03PM +0100, Cam wrote: > The 'strange behaviour' is that the transfer completes and the sender > seems to send a -1 (as seen in main.c) Not quite. The cause must come from someone calling either read_longint() or write_longint(), which can happen at the end of the t

Strange behaviour rsync pull from sun to ppc linux, Integer overflow - attempted 64 bit offset

Hi, I am running rsync on an embedded linux (ppc) like this: rsync -avvv sun::file-system/ /rsyncexperiment Where sun is a solaris machine that has rsync: rsync version 2.5.7 protocol version 26 Copyright (C) 1996-2002 by Andrew Tridgell and others Capabilities: 64-bit

Re: Identical files showing in dry-run

> What you should do is to drop the -I option and just use -c. The -I > option tells rsync to transfer everything. This doesn't have any change - it still transfers everything :( -Mark --- This E-mail is from IPC Media Ltd whose

Re: not sure how to read the log

On Thu, Jul 22, 2004 at 12:45:01AM +0200, Iavor Raytchev wrote: > rename "LOCAL_PATH_TO_E_MAIL_MESSAGE HERE" -> "REMOTH_PATH_TO_E_MAIL_MESSAGE_HERE": > No such file or directory > SAME_REMOTHE_PATH_TO_E_MAIL_MESSAGE_HERE That looks like the message from the end of the transfer, but it's hard to k

Re: HP-UX 11i and largefiles on rsync 2.6.2

On Wed, Jul 21, 2004 at 02:21:27PM -0400, Don Malloy wrote: > Hopefully this is of more help to you. Unfortunately I haven't been able to get rsync to fail in the update of a large file, and the system call trace you provided didn't tell me anything helpful in narrowing down what is going wrong.

O_NOATIME in linux 2.6.8rc2

linux 2.6.8rc2 gained an O_NOATIME open option, which allows you to make backups without affecting the atime. Someone might like to add this into rsync as an option. It should be pretty trivial. -- Martin pgpOjwszIPU8F.pgp Description: PGP signature -- To unsubscribe or change options: http:

Re: multiple rsync simlataneously

On Wed, Jul 21, 2004 at 07:51:56PM +0530, [EMAIL PROTECTED] wrote: > Please provide a good solution. The best solution is to not backup 100 hosts every minute. You'll probably have to stagger the hosts so that they don't all try to backup at the same time. ..wayne.. -- To unsubscribe or change

Re: Files to short after transfer

On Thu, Jul 22, 2004 at 04:03:26PM +0200, Mark Koennecke wrote: > - My command line: rsync -ruzv /home/TRICS/data/2004/ \ > /afs/psi.ch/project/sinqdata/2004/trics/ The -u option tells rsync to ONLY update the file if the timestamp is earlier than the timestamp of the sending file. Th

Re: odd issue.

On Thu, Jul 22, 2004 at 10:26:45AM -0400, Drew Weaver wrote: > Why is bashing saying that it cant find rsync even though rsync is then > executed? The remote bash is saying that. You can either fix the PATH on the remote box (e.g. make it so that "ssh -l root box2 rsync" outputs the rsync help te

Re: backup complete server

primary = 10.28.123.232 backup = 10.28.123.230 On the "primary" server, I have edited my rsyncd.conf file to the following: uid = 0 gid = 0 use chroot = no max connections = 4 syslog facility = local5 pid file = /var/run/rsyncd.pid read only = true list = false hosts allow = 10.28.123.230 [etc]

Re: Identical files showing in dry-run

On Thu, Jul 22, 2004 at 11:22:10AM +0100, Mark Round wrote: > rsync -Icrn --exclude='.svn' --stats -e "ssh" [source dir] > [EMAIL PROTECTED]:dest dir] > Any ideas what I'm doing wrong, or what I should be doing ? What you should do is to drop the -I option and just use -c. The -I option tells r

Files to short after transfer

High, I am experiencing a problem with rsync. The symptom is that rsync does not seem to notice that the file at the target side is shorter then the source one and then does not update the file. This leaves me with corrupted files at the target side. Now, this does not happen all the

odd issue.

This is a debian machine. #: /usr/bin/rsync -av -e /usr/bin/ssh /usr/box1backup-072104.tar.gz [EMAIL PROTECTED]:/root/box1backup-072104.tar.gz bash: rsync: command not found rsync: connection unexpectedly closed (0 bytes read so far) rsync error: error in rsync protocol data stream (code 12)

Identical files showing in dry-run

Hi all, I've got a problem with rsync 2.6.2 on Solaris/SPARC (one system is Solaris 8, the other is Solaris 9). I'm trying to get a list of files that have changed on one server (a development web server) and another (a live web server). I am using rsync as follows :- rsync -Icrn --exclude='.sv

Re: Avoid return code 24 (file vanished) with command line option?

On Wed, 21 Jul 2004 09:01:43 + (UTC), Robert Sander <[EMAIL PROTECTED]> wrote: > The backup process restarts rsync if it encountered an error condition. > But this error is not a "real" error. Problem fixed. I was able to change the backup script's behaviour. The script now treats rsync's ex