similar to: rsync Digest, Vol 5, Issue 19

On Tue, Sep 16, 2003 at 03:49:45AM -0700, jw schultz wrote: > > Aside from numerous other weaknesses that have crept into > the manpage i do note that there doesn't seem to be any > point where it is mentioned that rsync replaces destination > files rather than updating them in-place. I'm not sure > where it would go in the current manpage. > > I'm no writer

Dear JW, I spent hours checking and upgrading my hardware. There is nothing wrong with it. It is a 'mature' Pentium-II 400MHz system that has been running my servers WITHOUT ANY CRASHES for nearly 2 years now 24/7 Listen to me: "The crashes are dues to rsync" There is an IDENTICAL report from a totally different source at

On Thu, Aug 28, 2003 at 12:51:16PM +0300, Sviatoslav Sviridov/Lintec Project wrote: > > Sorry for direct reply, but mail server at samba.org blocks my messages. Postmasters, Martin, For your consideration. > Begin forwarded message: > > Date: Thu, 28 Aug 2003 12:43:54 +0300 > From: Sviatoslav Sviridov/Lintec Project <svd@lintec.minsk.by> > To: rsync@lists.samba.org

That's actually a very good suggestion. First I figured that in this way files changed within the hour after creation would be ignored, but they probably represent a very small minority anyway. On the other hand, this does not really rectify the situation, but will allow us to postpone the real sync again until, let's say a holiday, where we have plenty of time to sync. Rgds, Bart

This is just a trivial documentation change. The word "link" is overloaded. It refers to symlinks, hardlinks and network links. When looking for references to file links in the manpages the network references get in the way. This patch changes when reasonable to do so the word "link" to "connection" when referring to the network. This is just a suggested

On Tue, Nov 05, 2002 at 08:37:00AM -0800, Martin Pool wrote: > On 10 Oct 2002, "Green, Paul" <Paul.Green@stratus.com> wrote: > > No new CVS messages have appeared on the rsync-cvs archives since August > > 30th. This seems rather odd-- perhaps a daemon stopped working? If there > > has truly been no activity since that date, I apologize for > >

I just did a make clean to tidy up a bit and found four objects were missed. The seem to belong to the CHECK_PROGS set. Not sure where best to put them so created a CHECK_OBJS variable and added it to the clean rule. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and

This patch causes --exclude-from and --include-from to read from STDIN when given - for a filename. This was formerly incorporated in my --link-dest patch. Patch against current cvs. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt -------------- next part

I have hinted in the past of wanting to go to a more selective control of the output of rsync. Here it is. PROBLEMS with the existing --verbose et al. The simple incrementing verbose doesn't allow one to restrict stdout to what actually is of interest. For instance inside dirvish i don't care about directories, or any kind of non-regular file because they show up every time even if

Hi, Whenever i am using the command rsync --write-batch -av --stats `cat $1` -e ssh user@remote machine:/destination/ This is writing rsync_argvs files in the home directory as well as to the destination directory. Can anyone give me any idea as how to prevent the writing of rsync_argvs files in the home directory which is of no use. Regards, Surabhi. > ---------- > From:

I just reviewed the EXCLUDE PATTERNS section of the manpage and found that the declarative portion never actually states that only the part of the path that is relative destination is compared. I'm not quite satisfied with my text on this so if anyone has a better way of stating it i'm open to suggestions. Index: rsync.yo

On Mon, 15 Dec 2003, jw schultz <jw@pegasys.ws> wrote: > OK, first pass on TODO complete. .... This hardlink bug report is nearly 21 months old... So I took a look at it using 2.5.7. See below. > BUGS --------------------------------------------------------------- > > Fix hardlink reporting 2002/03/25 > (was: There seems

On Mon, 15 Dec 2003, jw schultz <jw@pegasys.ws> wrote: > OK, first pass on TODO complete. .... > PERFORMANCE ---------------------------------------------------------- .... > Traverse just one directory at a time > > Traverse just one directory at a time. Tridge says it's possible. > > At the moment rsync reads the whole file list into memory at the >

Steve Sills Platnum Computers, President http://www.platnum.com steve@platnum.com ----- Original Message ----- From: "Steve Sills" <steve@platnum.com> To: "jw schultz" <jw@pegasys.ws> Sent: Thursday, January 22, 2004 1:52 PM Subject: Re: Rsync's Speed > The source server is a Dual 800 Mhz /w a 7200 RPM 40 GB HDD, the dest server > is a P III 450 with a

Please CC me. I'm not subscribed. Attached is a patch against 2.5.4pre1 CVS current to add the --link-dest option so rsync will create hardlinks for unchanged regular files to a directory on the destination. This is like --compare-dest except that the result is not a sparse tree. Also included is extension to --(ex|in)clude-from to allow - for stdin. Could one of the maintainers please add

hi guys Environment 2 servers (SunOS 5.8) rsync 2.5.6 Problem For a disaster recovery solution, we are running trying to synchornize interwoven backup stores between these 2 environments (server A and server B) The rsync operation is initiated over the network using 'rsh'. Once initiated from server A the rsync operation freezes with no indication. When the debug flag is enabled we get

I have downloaded the source for rsync 2.5.6 and compiled it without adjusting any options, no problems. Performed a test copy of a file GT 2 GB and it failed. In the file configure I changed the line to "--enable-largefile", removed all the .o files, performed a ./configure, gmake, gmake install. Tried the test copy and again received the following error message: rsync:

Actually, what I do also propogates deletions. Since someone may unpack a tar containing files with earlier mtimes than a marker file, a simple --newer won't do it for us, either. Instead, I generate a list of all items, consisting of name and type, to which i append number of links, size, and mtime for files; link destination for symlinks; and for directories, fifos, chars, blocks,

I'm in the midst of coding a patch set for consideration that will bump the protocol version and have a couple of observations. The current minimum backwards-compatible protocol is 15 but we have code that checks for protocol versions as old as 12. If someone else doesn't beat me to it i'm considering cleaning out the pre-15 compatibility code. A backwards compatibility patch could

Hi, In http://sources.redhat.com/ml/cygwin/2002-09/msg01155.html, I noted that the often-observed hangs of rsync under Cygwin were assuaged by a call to msleep(). After upgrading my Cygwin environment to rsync 2.5.6, I'm seeing these hangs again, not surprisingly given a CVS entry for main.c notes that this kludge was not harmless: Revision 1.162 / (download) - annotate - [select for