similar to: Unexpected Tag Errors - Solution

Hi All. I've had this problem with rsync, the solution to which has been really evasive to me. Any help would be appreciated. I'm running rsync 2.5.5 between 2 SCO boxes and get random "unexpected tag" errors. Sometimes the unexpected tag is positive, other times negetive, and a retry of rsync usually manages to work the second or third time round. The disks are identical in

tridge and Wayne in particular: I checked in this patch, which is meant to consolidate the ones from both of you for handling EOF in a modules list. The idea is that we need to handle servers that just close the socket rather than sending a nice ending token, but we want to keep EOF detection on in general. (The IO code is such a mess!) -- Martin Index: clientserver.c

I've been studying the read and write buffering in rsync and it turns out most I/O is done just a couple of bytes at a time. This means there are lots of system calls, and also most network traffic comprises lots of small packets. The behavior is most extreme when sending/receiving file deltas of identical files. The main case where I/O is buffered is writes from the server (when io

Author of the message didn't include rsync@lists.samba.org in the reply, and I think this message is in topic. -------- Original Message -------- Subject: Re: rsync windows -> unix still hanging :( Date: Mon, 30 Dec 2002 16:10:32 -0800 From: Jim Kleckner <jek-cygwin@kleckner.net> To: Mike Rubel <mrubel@galcit.caltech.edu>, cygwin@cygwin.com Mike - Greger Cronquist and I

Platform: Compaq OpenVMS Alpha 7.3 Compiler: Compaq C T6.5 The following patch resolves compile problems with the IO.C module. The (char) type was being used where (void) was more appropriate based on the actual use of the code. The (char) type was also being used where the usage was actually an (unsigned char). const qualifiers were added to improve compile efficiency. EAGLE> type

Hello, I've been having all kinds of problems with rsync. I've tried versions 2.5.4-6. They all seem to have the same problems. Currently, I'm trying to use SystemImager, which uses rsync to transfer files. I get this: get_boel_binaries_tarball rsync -av 10.1.2.14::boot/i386/SMC/boel_binaries.tar.gz /tmp/ receiving file list ... ERROR: buffer overflow in recv_exclude_list rsync

rsync 2.5.0 still has a bug where it hangs under some circumstances. The hang is beyond my abilities to track down. I'll keep trying, though, but here are details in case they're of use to anyone else: - Code configured & built on Solaris 2.5.1. - Same binary run on Solaris 2.5.1 (client) and 2.8 (server). - Using rsh transport, but also fails with ssh - Does not fail with

Hi everybody, I use rsync v2.5.5 almost without problems, but it dumps core from time to time. Core was generated by `rsync'. Program terminated with signal 11, Segmentation fault. There is excerpt from gdb's bt: #0 0x2810106f in __sfvwrite () from /usr/lib/libc.so.4 #1 0x280fdfe1 in fprintf () from /usr/lib/libc.so.4 #2 0x281002b6 in vfprintf () from /usr/lib/libc.so.4 #3

Hey guys, I've been working with rsync for the last couple weeks and I really need some help here. Linux to Linux transfers are working beautifully, but for the life of me I can't get transfers from win2k to work. I have the exact problem that was reported by Mark de Jong on Tue, 16 Jul 2002. I'm using the lastest version of cygwin, with rsync 2.5.5 and ssh 3.5p1 for my tests. The

-----BEGIN PGP SIGNED MESSAGE----- I added the following code to log_exit(): void log_exit(int code, const char *file, int line) { static int error_count=0; if(error_count++ > 10) { abort(); } To force it to bail earlier instead of overflowing the stack. As you can see at frame #50, it is trying to log that the connection went away unexpectantly.

There are quite a few compilation warnings from rsync-2.5.5rc1 that could be eliminated by code cleanup. gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -c main.c -o main.o main.c: In function `start_client': main.c:665: warning: unused variable `write_batch' main.c:664: warning: unused variable `whole_file' These warnings will go away when the two variables are properly bracketed

Yes, it's time once again to return to the subject of moving files. With the recent changes to the communications code between the receiver and the generator, there is now a non-clogging channel that we can use to signal the sender when a file has been successfully transferred, which allows us delete the original for all transferred files. I have in the past waffled on whether this feature

On Fri, Jun 04, 2004 at 01:20:54PM -0400, Joey Hess wrote: > My colocated server was refusing both ssh and ssl telnet connections. > It looked like this: > > joey:~>ssh -v kite > OpenSSH_3.8.1p1 Debian 1:3.8.1p1-4, OpenSSL 0.9.7d 17 Mar 2004 > debug1: Reading configuration data /home/joey/.ssh/config > debug1: Applying options for kite > debug1: Reading configuration

Since writing this I've recompiled with zlib 1.1.4 and everything appears smooth. Since this is intermittant, I'll send it off anyways in the hops that someone else may see it. It also *might* apply to the "known issues" entry about "unexpected close." (Similar symptoms, but it may just be a shared codepath on the messages. Note that the dumped len in my output(4)

I teach biology, and would like to show the students how to use R for some statistical assignments. One of those is to make a kite diagram (for example as seen in http://www.medinavalleycentre.org.uk/images/Bembri1.jpg). Is there any way to create one using R? I did a help.search("kite") and looked on the r-project HP with no luck. Previously when the course was taugh the students have

Dear member, When I run a code on a computer B from a computer A through shh using for example: system("ssh login at IPadress \"R -e 'print(1)'\"") [Note that I don't need indicate password because ~/.ssh/authorized_keys is used] I get a warning: During startup - Warning message: Setting LC_CTYPE failed, using "C" The code is working (it prints 1)

Dear everyone, I would like to create a kite chart in which I plot densities (width of the vertical kites) in relation to sediment depth (on reversed y-axis) for 6 different locations (Distances from seep site, on x-axis on top of the plot). The dataset I would like to use is: Distance_from_seep_site Sedimentdepth Density 1100 0 107.8 1100 1 264.6 1100 2 284.2

Hi, WE MADE THE CHANGE OF PERMISSION as chown -R sphynx:sphynx /var/log/icecast THEN ATTEMPTED TO START THE SERVER BUT HERE IS THE ERROR THAT RESULTED: [sphynx at sphynxradio ~]$ chown -R sphynx:sphynx /var/log/icecast [sphynx at sphynxradio ~]$ icecast -c /usr/local/etc/icecast.xml Server startup failed. Exiting [sphynx at sphynxradio ~]$ WE ALSO DID IT AS ROOT AND RETURNED THE SAME ERROR AS

Hi I am trying to compile rsync-2.5.5 on Tru64 UNIX V5.1A The configure completed sucessfully however the make failed. The following is a copy of the configure and make output. Could you please provide advice as to why this is failing and hopefully resolution. Just as a matter of comparison - rsync-2.5.4 make also fails, however, rsync-2.4.8 compiled sucessfully on this version of Tru64 5.1A

This is a multipart message in MIME format. --=_alternative 00812CFCCA256D66_= Content-Type: text/plain; charset="us-ascii" Two points in respect to PR#2867. First, the trivial one: (1) In Lapack.c, on lines 806 and 812, there are calls of F77_CALL(dgeqp3). But the error messages on lines on lines 809 and 815 refer to "dqeqp3", i.e., they currently have a "q"