similar to: Next release of rsync - when?

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

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.

(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

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

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):

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

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

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

With regard to this NEWS item from 2.6.1pre-1: * The --hard-link option now uses the first existing file in the group of linked files as the basis for the transfer. This prevents the sub-optimal transfer of a file's data when a new hardlink is added on the sending side and it sorts alphabetically earlier in the list than the files that are already present on the receiving side. I

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

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.

OK, I will do that next. I just tried 2.6.1 on both ends, and it died in a similar fashion. -------Original Message------- > From: Wayne Davison <wayned@samba.org> > Subject: Re: rsync 2.6.2 crash > Sent: 24 Sep 2004 11:21:51 > > On Fri, Sep 24, 2004 at 11:09:26AM -0700, jim wrote: > > The server crashed, but left rsync.exe.stackdump: >

This is a patch made by the redhat folks. I noticed it in their src.rpm for rsync while I was updating it for 2.5.7. I figure at the worst, it's a nice bit of protection. It would be cool to get this put into CVS. -- Kees Cook kees@kernel.org -------------- next part -------------- --- rsync-2.4.6/main.c.foo Fri Aug 17 11:46:03 2001 +++ rsync-2.4.6/main.c Fri Aug 17 11:45:37 2001 @@

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

Hello, I bumped in to issue with rsync 2.5.6 while doing "sync" of large files. Here is the error message.... "write failed on cm3.0_hpux11.11_final.tar : Error 0 rsync error: error in file IO (code 11) at receiver.c(243) rsync: connection unexpectedly closed (13342 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(165)" There is lot

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 >

I've released version 2.6.0 of rsync. Two important things to note in the new release: 1. The default remote shell is now "ssh" unless you tell the configure you want to use something else. 2. Some bug fixes in the include/exclude code, while making things work properly, have resulted in some user-visible changes for certain wildcard strings. Read the

On Sun, Dec 14, 2003 at 11:32:07PM -0600, John Van Essen wrote: > would you care to take the bull by the horns and produce a release > candidate for 2.5.8 so that the rsync enthusiasts on the rsync mailing > list can give it a whirl prior to an official release (hopefully by > Christmas)? I was just about to say something about this on the list, so I'll do it in reply to your

OK, I packaged up the current CVS as our first preview release for 2.6.0. You can grab it here: http://samba.org/ftp/rsync/preview/rsync-2.6.0pre1.tar.gz The MD5 checksum is: 70e9dea967f083c231b7821ef35aef1b rsync-2.6.0pre1.tar.gz There is not currently a .sig file for the package, but I'm looking into that next. Please test this and let me know if we have any remaining issues