similar to: PATCH/RFC: Another stab at the Cygwin hang problem

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 17:24:47 -0800 From: Jim Kleckner <jek_subs@kleckner.net> To: Mike Rubel <mrubel@galcit.caltech.edu> CC: cygwin@cygwin.com References:

FYI, We've been using the 2.4.7pre1 release for several days now, with nary a hang problem. We haven't seen the EOF bug at all, which was what we upgraded for. This is with transfers of as much as 50GB to set up an initial mirror. The only thing we did was set timeout=0 -- which I guess is unnecessary. The semantics of this flag are a bit unclear. We thought was 'time since

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

Some of the debug messages that rsync outputs (when verbose >= 2) can occur on both sides of the connection. This makes it hard to know which program is saying what. Some debug messages deal with this by outputting a "[PID]" string at the start of the message. Unfortunately, the startup message that tells us which pid is which is only output when verbose >= 3, so there's a

People of cygwin & rsync, I recently attempted to get cygwin and rsync working to solve a backup/mirroring need in my computer life. Well, as you might guess, I ran into a little but of trouble. Strangely enough, rsync seemed to be regularly hanging when I attempted to do a "get" (sycronize a remote to a local dir). Well, considering I want to automate this, that was not going

Here's a patch that makes rsync try to find an existing file in a group of hard-linked files so that it doesn't create the first one in the group from scratch if a later file could be used instead. Details: I decided to avoid having the code do an extra scan down the list when we encounter the lead file in the list. This is because it would be bad to have to do the same scan in the

In case others find this of value, I wrote a patch to rsync 2.5.6 to give rsync in --daemon mode the ability to run a pre-transfer and post-transfer command. These options handle our need to prepare a server to receive files and to do some processing after receiving files. The options for /etc/rsyncd.conf are pretransfer script = /some/command/to/run posttransfer script =

Hello everyone! I didn't find anything in the archives that seemed similar (same error, different offending lines of code). I'm having an issue with rsync on a couple of my servers. A couple of others run just fine but 2 of them give me the same message (see below) when I try to do backups from one server to these linux boxes. All of the linux boxes are the same and have the save

Wayne, Please consider the attached patch. This applies to the current CVS, and is independant of patches/local-batch.diff. As a matter of fact, I'm sure it would conflict heavily with local-batch.diff. This version of batch mode has a couple distinguishing features: Write-batch records (almost) the entire sender side of the conversation into one file. ("Almost" because it has

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

Dear rsync folks, I'd like to request/suggest that cli options to set TCP send/receive buffers be added to rsync client-side. Summary: I'm aware that a daemon's config-file can set socket options for the server side (e.g. SO_SNDBUF, SO_RCVBUF). That is useful. But when trying to get high-throughput rsync over long paths (i.e. large bandwidth*delay product), since

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

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. I once tried to rsync around 100 GB (10 million files), but version 2.6.6 needed too much RAM and was too slow. Is one of the snapshots stable enough to try this again? Greetings Sven -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url :

This mode is useful when a process is monitoring the log for post-processing of transferred files. With --log-after in local mode, both sender and receiver log to the same log file, so it require --log-file with absolute path. We add %o to the default log format, so it will be easy to tell the logs of the sender from the logs of the receiver: 2023/02/14 14:40:25 [559755] building file list

[This is a copy of the contents of Debian bug report #147842.] Package: rsync Version: 2.5.5-0.2 Severity: normal Cause ----- - rsync forks a child which in turn forks a grandchild in main.c:do_recv(). - Diagnostics written by the grandchild need to be read by the child using read_error_fd() to be handled properly (with the end result being that they are seen by the user running rsync). -

https://bugzilla.samba.org/show_bug.cgi?id=4139 Summary: Generator process (running as daemon) hangs after kill SIGINT. Product: rsync Version: 2.6.8 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org

Hi, One feature missing from rsync, and requested on this list before, is on-the-fly conversion of filename character encoding. For example, I often need to sync files having Hebrew filenames from a UTF-8 system (Linux) to an ISO8859-8 system (Cygwin on Windows 2000 using the non-Unicode Win32 interface). Other circumstances surely abound. Attached is a patch against rsync 2.6.2 that adds an

> Just curious: what about the rsync+ patch? Thanks for the reminder. I've just committed Jos's rsync+ patch onto the "branch_mbp_rsyncplus_merge" branch. If it works OK and nobody screams I will move it across onto the main tree tomorrow or Wednesday. I see the patch doesn't add documentation about the new options to the man page, so we should fix that in the future.

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