similar to: @RSYNC EXIT / @RSYNC EOF

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

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

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

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

On Wed, Jan 30, 2002 at 06:03:10PM -0500, Bill Nottingham wrote: > Dave Dykstra (dwd@bell-labs.com) said: > > I stumbled across the bug report > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=58878 > > > > which shows that you made a bug fix to rsync on Sunday. What exactly did > > you do? > > Attached. It's the same thing as yours, I just

Wayne, It's taken a little while for me to get more familiar with the code, but I think I've reached a good breakpoint in improving batch-mode. Let me highlight some of the changes in the attached patch: * --write-batch and --read-batch arguments are no longer passed from client to server. This fixes the current problem that causes the server threads to die when the client

From: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> zstd compression was announced as "good compression with high throughput" so I gave it a try. With zlib, on high speed links the CPU is usually the bottle neck. With zstd I'm able to fill a 200Mbit link :) zstd detection happens automatically via pkg-config. No zstd header means no error about missing zstd. So that

Here is a diff which should allow applying batch updates remotely ( as apposed to copying the batch files to the remote server and running rsync there ). Eg rsync --write-batch=test src dst1::dst rsync --read-batch=test dst2::dst Oli Dewdney diff -E -B -c -r rsync-2.5.6/flist.c rsync-2.5.6-remotebatch/flist.c *** rsync-2.5.6/flist.c Sat Jan 18 18:00:23 2003 ---

Rsync-2.5.2 does not gracefully report connection and transfer errors and always properly return with a non-zero exit code, despite many assurances to the contrary in the code and commit logs. It seems a kludge to handle a special case of lost connections to older servers was FAR too aggressive! With '-vvv' I also print the source of the exit_cleanup() call, and optionally with

Hello, Recently I noticed a disparity in the use of HOST::MODULE and rsync://HOST/MODULE syntax by rsync. HOST::MODULE can be used to both pull from and push to a remote rsyncd server, but rsync://HOST/MODULE can only be used to pull from a remote rsyncd server. The attached patch resolves this issue by also allowing a rsync:// URL to be used to push files to a remote rsyncd server. Testing:

Greetings and salutations, rsync users. I have a problem. I'm hoping that someone out there could perhaps provide a hand. I've been trying to transfer large amounts of data (lots of data, lots of files) via rsync over an encrypted TCP tunnel, but I seem to be continually getting hangs in the transfers -- things will go along for a bit, and then just come to a screetching halt. There

Hi, I think I found a bug in usage of zlib. rsync 2.5.6 with -z fails like bellow. % cp install-disk2.iso /var/tmp/install-disk2.iso install-disk2.iso 100% |*****************************| 316 MB 00:56 % rsync -vIz install-disk2.iso 127.0.0.1:/var/tmp/install-disk2.iso install-disk2.iso deflate on token returned 0 (16384 bytes left) rsync error: error in rsync protocol

Hi Folks -- I've recently had the need to add a piece of functionality to rsync that allows one to run 'rsync --daemon' (rsync in "rsync server" mode) over SSH. My main goal was to be able to use some of the features from rsyncd.conf(5) (notably modules) while still using SSH for authentication and network transport. Background: I wanted to have the capability of setting

Hi all. After weeks of debugging etc. I found the problem. It would seem like its a compiler error on SCO, because in line 286 of io.c - read_unbuffered() - it declares a 'static' variable (type size_t) called 'remaining', and while the ANSI standard says that static vars are automatically initialised to zero, it would seem that this is not always the case. By explicitly

When a whole-file checksum is performed, hashing was done in 64 byte blocks, causing overhead and limiting performance. Testing showed the performance improvement to go up quickly going from 64 to 512 bytes, with diminishing returns above, 4096 was where it seemed to plateau for me. Re-used CHUNK_SIZE (32 kB) as it already exists and should be fine to use here anyway. Noticed this because

I'm backing my Ubuntu server up to an HFS+ case-sensitive volume on our iMac using the below rsync command and it hangs at the end. Compiling rsync 3.0.8 by hand with CFLAGS=-g on both systems shows that all rsync processes are in read_timeout(). $ rsync \ --delete-delay \ -P \ -v \ -A \ -X \ --fake-super \ -aH \ --numeric-ids \ --exclude '/dev' \

I've noticed the 3.0.0pre versions sometimes hanging while doing a local copy (through dirvish). This time a had a binary with debugging symbols, so I could do gdb backtraces. This is the result: # ps -fe | grep rsync root 3712 3710 0 02:04 ? 00:00:03 rsync -vrltH --delete -pgo --stats -D --numeric-ids -x --exclude-from=/backup/0/oudeserver/laatste/exclude

https://bugzilla.samba.org/show_bug.cgi?id=5701 Summary: deadlock on local rsyncing, bisected to commit f303b749f2843433c9acd8218a4b9096d0d1bb8d Product: rsync Version: 3.1.0 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P3 Component: core AssignedTo: