similar to: Stop password errors from getting reported as transfer errors

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

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

Hello, There is still a problem with the _exit_cleanup() function in cleanup.c despite the patch that was put in last week that prevented recursion. It turns out that sometimes multiple calls in close sequence are done and this causes rsync to spin out of control instead of exiting. This bug was found by Marc Espie and the patch I'm including is his as well. It hasn't been commited

A new 2.6.0 feature is supposed to use a different exit code when the only 'errors' were from files that disappeared between the building of the file list and the actual transfer of files. But if the client is local and the server is remote, IOERR_VANISHED gets set on the remote server, but is never passed to the local client (the io_error value is passed at the end of the file list, not

Hi, The problem I found is not in what rsync, but on the error handling: How to reproduce: On server side I setup a tree and share using rsync + xinetd, of course, for security reason I use chroot option. Now I push this symlink: lrwxrwxrwx 1 root root 4 nov 10 16:28 horsroot -> /bin/ Now I try to do: ./rsync -avPH --copy-unsafe-links draco::test/ /tmp/rsyncdest/ (Of course the

seems the behavior of rsync has changed when dealing with output and using both -v and -q at the same time ... for example: $ mkdir test1 $ touch test1/foo $ rsync-2.6.0 -avq test1 test2 $ rm -r test2 $ rsync-2.6.8 -avq test1 test2 test1/ test1/fo $ rm -r test2 $ rsync-cvs -avq test1 test2 building file list ... test1/ test1/fo $ rm -r test2 the new output in 2.6.8 comes from the calls to

Hello, I wrote this patch that allows you to run rsync over an existing I/O connection, instead of creating a new rsh or socket connection. For example, I have a client and server that talk over ssh via a simple custom protocol. I want to use the existing ssh connection to transfer files, but I want the flexibility of rsync to do it. With this patch, I can do the following in my client

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

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

Here's a resend of an old patch that is intended to avoid an infinite recursion (ending in a stack overflow) of the rwrite() function getting an error that calls rwrite(), ad naseum. I've only seen this happen when one of the sides dies due to a program error -- in that case, the connection is closed, and when we try to send an error to the other side and it generates an error, the error

Using rsync 2.6.0 with --verbose and doing a pull. >?receiving file list ... readlink "{FILENAME}" failed: >?No such file or directory >?done >?IO error encountered - skipping file deletion The file was a temporary file that was being deleted just as the rsync was run. So while the file list was being built, it was there when the directory was read but had vanished by the

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

Dear All, We sometimes have to replicate large "live" filesystems with many ( sometimes millions, up to few hundred millions ) files on them. ( Copying actively used files is of course a bad idea, but it really helps to keep the delta small, so one final transfer can later save the day. ) The problem, as one may guess, is that some files may disappear during the process, so rsync

Hi all, Well, yeah, that's it, really. :-) Try it. Works consistently, on Doze and Linux here ... # rsync -vvrlHSPtiypogD --stats --numeric-ids --delete-after --force -- partial-dir=.partial /tmp/ /var/tmp/ [...show stats...] unknown message 4:1 [generator] rsync error: error in rsync protocol data stream (code 12) at io.c(307) [generator=2.6.9] rsync: connection unexpectedly closed (26

Hiya, I can see it's a regular subject on this list. I, like others wanted to use rsync to synchronise two block devices (as it happens one lvm volume and one nbd device served by qemu-img on a remote host from a qcow2 disk image so that I can keep the old versions) As I couldn't find any report of it being done successfully, I'm just sharing my findings as it might benefit others.

hi. return value of close() (receiver.c) is ignored. when running out of quota on NFS (for example), this can happen (without the patch): output file(s) is/are truncated to 0 bytes and rsync reports success. with the fix, this happens: close "/home/luser/.test.mp3.PwaG50": Disc quota exceeded rsync error: error in file IO (code 11) at receiver.c(464) ... ...and additionally, test.mp3

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

The second rsync-2.5.6 pre-release version is now available at: http://rsync.samba.org/ftp/rsync/preview/rsync-2.5.6pre2.tar.gz ftp://rsync.samba.org/pub/rsync/preview/rsync-2.5.6pre2.tar.gz rsync://rsync.samba.org/ftp/rsync/preview/rsync-2.5.6pre2.tar.gz There's also a corresponding '.sig' file that contains a gpg signature of the file; the public key is available on the

This draft patch adds support for transferring extended attributes with a new --xattr option. It ought to work on Linux with XFS or ext2/ext3 filesystems with the SGI/bestbits attribute system. It is partially working, but there seems to be some kind of hang bug while transferring the file list. I suspect it might be provoking a problem in io.c. You need to rerun autoconf, autoheader and

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