similar to: pre-xfer exec fails in FreeBSD

To Whom It May Concern: Below is a patch, that I have used to eliminate the unexplained errors in the rsync program. I was able to trace the problem to the order in which the sigchld_handler and wait_process routines were executed. If sigchld_handler executes first it retrieves the status that wait_process needs to indicate proper rsync termination. The code below allows the sigchld_handler to

I believe I have found the cause of the unexplained error (code ??) at main.c(line #). In the version I'm running 2.5.2 (obtained from the Free Software Foundation) the line number is 576. It appears the root cause is related to a race condition associated with the termination of child processes. If the signal handler for SIGCHILD is executed, as the result of a child termination, before the

Hello, I like to use rsync to transfer over mine and other peoples ever changing mail folder onto a remote server. My Server (FreeBSD 5.4) RSYNC Version is: 2.6.6 Protocol Version 29 My Client (OSX 10.4.2) RSYNC Version is: 2.6.3 Protocol Version 28 I use this command rsync -vvv --progress --stats --recursive --times \ --perms --links \ --delete /test/my?email?folder/*

A google search on this problem did not show any matches, so I'll take the chance that someone on this list might consider it an rsync problem. In a nutshell, if rsync forks a child process to handle the transport (rsh in this case) it can hang in wait_process() forever waiting for that child process to die. Normally this would not be a problem. However, if the wrong packet is dropped

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:

Hi. We sometimes/often get such errors. It occures in main.c/client_run(). I investigated further and found, that the waitpid() in main.c/wait_process() exits with -1, errno = ECHILD, which means "No children". *status can contain garbage in such cases - but not always. It happens under Solaris-2.5.1/SPARC. It (ECHILD) also happens on other Solaris versions - but there *status seems to

Initial problem: When running 'make test' the hands.test fails as indicated in problem #3711 and includes the line rsync error: unexplained error (code 63) at main.c(537) The code # changes each time the test is run. Using HP C-ANSI-C B.11.11.02. configure line: CFLAGS="-O" ./configure --prefix=/opt/local In tracking this down, this is what I found: In main.c a

I compiled rsync-2.5.5 on HPUX 11.11, using the +DA2.0W and +O3 options. invoking a simple rsync to transfer a file works (I ran a diff on the file, no changes) e.g: sdx1 214: ./rsync --rsh='/usr/bin/ssh -x' --rsync-path=/usr/local/src/rsync-2.5.5/rsync /scratch/chuck/tmp.test sdx2:/scratch/chuck However, adding the -a option yields an unexplained error: (In all of the following cases

Hi, In http://sources.redhat.com/ml/cygwin/2002-09/msg01155.html, I noted that the often-observed hangs of rsync under Cygwin were assuaged by a call to msleep(). After upgrading my Cygwin environment to rsync 2.5.6, I'm seeing these hangs again, not surprisingly given a CVS entry for main.c notes that this kludge was not harmless: Revision 1.162 / (download) - annotate - [select for

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 =

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 had a friend run some Cygwin tests and we found that --modify-window=1 works just as well as --modify-window=2 on FAT filesystems to copy files from Unix and detect the difference in granularity. FAT filesystems always have timestamps that have an even number of seconds. On the other hand, NTFS filesystems can store the modification time down to the second, whereas previously people on this

Hi, Please try this patch below, I think it?ll solve the bug? Amir diff -U 5 -Nuir rsync-3.0.4/cleanup.c rsync-3.0.4.new/cleanup.c --- rsync-3.0.4/cleanup.c 2008-06-04 19:01:02.000000000 +0300 +++ rsync-3.0.4.new/cleanup.c 2009-03-29 09:45:04.000000000 +0300 @@ -98,11 +98,11 @@ static int unmodified_code = 0; SIGACTION(SIGUSR1, SIG_IGN); SIGACTION(SIGUSR2,

Trying to figure out this problem. RSYNC maybe once a day or so will just hang and sit there... strace attached to the process produces the following... I wonder where the loop is. Anything I can do to help would be fabulous. Most of the time it works fine. Very strange. -- Mike gettimeofday({1022283618, 513186}, NULL) = 0 wait4(22167, 0xbffff9e8, WNOHANG, NULL) = 0 gettimeofday({1022283618,

Hi, I needed to filter content of files (encrypt), before they are sent over the network to backup server. The easiest way to do this was modifying Kyle Jones's "--dest-filter" patch. Somebody was asking there this feature in the past, so I'm sending this patch to list. Implementation details: -filtering disables rsync alogrithm -source filter makes temporary files in /tmp

I'm working on trying to get rsync 2.5.6pre1 available for people to test more widely. I'm out of time for today, and I'm stuck on a problem that some machines on build.samba.org are showing on the 'chgrp' test. I can reproduce this on my home redhat 7.3 system too. It appears to be a timing problem because when I do strace -F -f on it the problem goes away. Everything seems

As I reported a while back rsync doesn't handle metadata (permissions and ownership) in dryrun mode. I offered to make a patch and that offer still stands. I didn't have the time for it until now and want to pick it up again. I had some ugly hack back then but I want to redo it in a clean way. I would like some input on my thoughts. IMHO, it would be ideally if the check for dry_run

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

It seems there's no way to transfer files to/from 5.9 to/from Android 4.1.1 using bluetooth, at least that's what the web and my attempts have been telling me for the past few days. Or has someone found a way...?

Hi all, Is there any way to determine transfer direction (download/upload) in pre-xfer and post-xfer rsync daemon scripts? I want to trigger notification event upon successful upload. If not, consider this to be a feature request for additional environment variable.