similar to: --hard-link option now uses the first existing file - Excellent!

On Wed, 7 Jan 2004 17:33:36 -0800, Wayne Davison <wayned@samba.org> wrote: > On Wed, Jan 07, 2004 at 04:15:57PM -0800, jw schultz wrote: > >> Runtime variable sized structures should be avoided. Do you want >> to make rdev, link and sum conditional also? > > The difference between these other items you mentioned is that we aren't > talking about making them

(As I was composing this, the 2.6.1 release notice on the rsync list rolled in. The quoted source, below, hasn't changed, so I'll leave the 'pre-1' references unchanged...) I have a situation where an error message seems to be sent from the daemon to the client, but none is logged in the daemon's log. Daemon is 2.6.1pre-1, with --timeout=3600, light CPU load. Client is

I've been using the --keep-dirlinks feature of 2.6.3pre1. I also use -x (--one-file-system) and --delete-after. The symlinked directories on the receiver are symlinked to a partition other than the one where the target of the rsync resides (that's the whole point of this nifty --keep-dirlinks feature). I discovered that the symlinked directories are not being processed for deletions.

On Mon, 9 Dec 2002, Martin Pool <mbp@samba.org> wrote: > >Mailman holds some suspicious messages for filtering by the admin. >However, for samba.org, this means about 80 messages per week, which >have to be handled through a clunky web interface, and which take time >away from more useful tasks. This is not acceptable. Pah! :) Try 100+ messages per day, with 200+ at the

On Mon, 10 Nov 2003, Wayne Davison <wayned@samba.org>?wrote: > >?... This fix is also in CVS (along with several others). As another poster pointed out recently, it's been a long time since 2.5.6 was released (Jan 28 2003). Many recent replies to questions posted to this list are variants of "It's already fixed in CVS". Are there any particular reasons for holding

Using rsync 2.6.0 with --verbose and doing a pull. >?receiving file list ... readlink "{FILENAME}" failed: >?No such file or directory >?done >?IO error encountered - skipping file deletion The file was a temporary file that was being deleted just as the rsync was run. So while the file list was being built, it was there when the directory was read but had vanished by the

One thing that's bugged me is that some of the man page lines in the options summary are longer than 79 chars and wrap onto the next line. These are just one line summaries (detailed description appear later) so they can, and should, be terse. Here's an edited diff showing my proposed changes (and a 79 char ruler):

A new 2.6.0 feature is supposed to use a different exit code when the only 'errors' were from files that disappeared between the building of the file list and the actual transfer of files. But if the client is local and the server is remote, IOERR_VANISHED gets set on the remote server, but is never passed to the local client (the io_error value is passed at the end of the file list, not

Since the heap statistics were added, I have viewed thousands of rsync reports (with --verbose and --stats), and not once have I had a need for them. So for me, they're just noise. Here is a 3-part patch to v2.5.6 that treats --stats in a similar fashion to --verbose in that additional --stats will get you more statistics. For this initial case, there's only one additional level of

To the rsync maintainers: When rsync 2.5.5 is pulling files and the target disk runs out of space, this is what the tail end of the message stream looks like (w/--verbose): write failed on games/ghostmaster/ectsdemo2002.zip : Success rsync error: error in file IO (code 11) at receiver.c(243) rsync: connection unexpectedly closed (152112 bytes read so far) rsync error: error in rsync protocol

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 >

Patches welcome, eh, Paul? Upon further (belated) investigation, there are 2 affected places in receiver.c with this error message. Both call write_file(). And write_file is called only in those two places. So that is the appropriate location to patch. Especially since the obvious fix is to use the rewrite code already there for the sparse file writes.

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

So I'm doing daily backups with rsync, and weekly, I run it with --delete after archiving the whole thing (this way I don't lose any deleted files). All week long this runs fine, but when I add --delete, rsync runs for a few hours then aborts because the box runs out of memory. Jan 30 06:31:09 backup kernel: Out of Memory: Killed process 3490 (rsync). Source box: RH8+Custom Patches Rsync

I'm using 2.6.3pre1 to transfer a rather large Debian archive (126GB, more than 30 million files). It contains about 450 daily snapshots, where unchanged files are hardlinked between the snapshots (so many files have hunderds of links). It's been running for some time now, and I found that while it's far from done, it's already used 165GB on the receiving end. Investigation shows

Hello. Recently, I started using rsync to backup files in my root partition on an Ensim box over to a remote machine. The remote machine 'pulls' from the Ensim box using the following: rsync -arvzx --exclude=/proc --exclude=/tmp --exclude=/mnt --delete --delete-excluded -e ssh 192.168.0.1:/ /bkup/rootpart/ The problem is, if I 'df' the Ensim box, it reports that the entire

There is a new patch named "delete-during.diff" in the CVS "patches" dir. This patch adds the ability for rsync to incrementally delete files in each directory during the normal course of the transfer rather than doing a separate delete scan either before or after the transfer. The patch renames the current --delete option into --delete-before and makes --delete behave in the

The rsync 2.5.6 TODO file mentions the need for hard link test cases. Here is one in which a linked file is unnecessarily transferred in full. # Setup initial directories mkdir src dest dd if=/dev/zero bs=1024 count=10000 of=src/a 2>/dev/null rsync -a src/. dest/. ln src/a src/b # At this point, a & b exist in src; only a exists in dest. rsync -aHv src/. dest/.

Hi, sorry if this is old stuff, but I did my best to look first... Have been getting errors along these lines: mv mydir mdir.2002 ln -s mydir.2002 mydir Then update mirror with rsync -av --delete-after. Without --delete-after, no problem, with --delete-after, get a code 23. The attached shell script will recreate the error (on my machine, at any rate). Just run it from a clean directory.