search for: betageek

On 10/15/07, Erik Jan Tromp <betageek@sympatico.ca> wrote: > # The second error > Invalid file index: -101 (-1 - 0) with iflags 0 [receiver] > rsync error: protocol incompatibility (code 2) at rsync.c(273) [receiver=3.0.0pre2] > rsync: connection unexpectedly closed (21 bytes received so far) [generator] > rsync error...

Just tripped over this one today. $ rsync --no-motd rsync://alphageek.dyndns.org/slackware rsync: link_stat "." (in slackware) failed: No such file or directory (2) rsync error: some files could not be transferred (code 23) at main.c(1498) [receiver=3.0.1pre2] $ rsync --no-motd rsync://alphageek.dyndns.org/slackware/slackware-current drwxr-xr-x 4096 2008/03/26 01:30:27

It would appear something snuck in that breaks non-recursive remote listings when talking to a non-3.0.0pre1 version of rsync. The symptom itself is simple enough to see; rather than displaying member directories/regular files/symlinks/etc as one would expect, only non-directories (with the exception of '.') are listed. Other tidbits.. some obvious, some maybe not: - not limited to just

Oops :) -- quote -- $ rsync -aHPv rsync://host/module/single.file . <motd, if any> receiving file list ... 1 file to consider Segmentation fault -- endquote -- The rsync process remains running until explicitly 'kill'ed. At which point, the following is printed: -- quote -- rsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(225) -- endquote -- -- quote -- $ rsync -aHPv

Synopsis: Prior to the 2.6.4pre versions, issuing 'rsync rsync://host/module/' behaved effectively as 'ls -l'. I've toyed with various options in an attempt to get an 'ls -l' style output, but to no avail. As I have a small handful of scripts that rely on this no-longer-functioning functionality, this could be considered a Bad Thing(TM). Following is an example of

I've been reworking my backup script & decided to give some of the newer options a try. It would appear I've found a combination that doesn't play nice. $ rsync --archive --delete-during --fuzzy --hard-links --numeric-ids --quiet --sparse --temp-dir /backup/helium/ --link-dest /backup/hydrogen/tuesday/ --password-file /backup/helium/.password rsync://backup@helium/backup/

Continuing with my backup script (see previous post), I've found a small oops regarding the 'max verbosity' option for rsyncd.conf In the manpage this option is listed as a module option. Poking through the source, however, shows that it's parsed as a global option (loadparm.c). If it's a question of which end to change, I would find this option being per module much more

Wayne, I've been experimenting with the {pre,post}-xfer exec options ever since the original diff showed up in patches/ - fantastic stuff. My feature request/change centers around the new RSYNC_ARG# variables. Would it be possible to make these available as an array (ie: ${RSYNC_ARG[#]}) rather than discrete variables? If nothing else, it would greatly simplify chewing through all the args

3.0.0pre2: non-recursive remote listing breakage Looks like pre1's fix broke something else. I noticed this when listing module/directory contents on servers known to be running versions 2.5.7 & 2.6.3. Not having (full) access to them, I replicated the errors using 2 machines on my home lan. # the machines lithium.elements.lan: the client. rsync 3.0.0pre2 for all tests.

Just a quick heads up to say I'm still getting this (reproducable) error while doing daily backups: rsync: generator.c:1872: check_for_finished_files: Assertion `flist != ((void *)0)' failed. rsync: writefd_unbuffered failed to write 4092 bytes [receiver]: Broken pipe (32) rsync error: error in rsync protocol data stream (code 12) at io.c(1500) [receiver=3.0.0pre2] This is with cvs

I upgraded to pre3 a couple hours ago & right now I'm watching my 00:00 backup set absolutely _crawl_. Typically, backups would have been finished somewhere in the 00:10 to 00:30 range, depending how much data changed across 6 machines in the past day. As I write this, the 3rd of 6 machines is (hopefully) just finishing its backup with no more than the usual changes per machine. Whiskey

# The first error rsync: generator.c:1867: check_for_finished_files: Assertion `flist != ((void *)0)' failed. rsync: writefd_unbuffered failed to write 4092 bytes [receiver]: Broken pipe (32) rsync error: error in rsync protocol data stream (code 12) at io.c(1493) [receiver=3.0.0pre2] # Sample command, obfuscated to protect the guilty rsync --archive --hard-links --no-motd \ --numeric-ids

I had noticed the --link-by-hash patch a short while back & decided it was time to experiment with it. Sadly, its behaviour is considerabely different from what I expected - to the point that I find it unusable in its current form. I had hoped to use it both for my rotating backups & for my (unofficial) slackware mirror. For the test itself, I did the following: - created 3 directories in

The background: I host one of the unofficial slackware mirrors & push to a high speed (unlisted) mirror that several other unofficials use for pulls. To save time/disk/bandwidth I use a custom script to hardlink the trees prior to pushing the updates to said unlisted mirror. The commandline (linewrap from hell, sorry): (note: username/password/hostname/modulename deliberately obfuscated)