similar to: Modified --files-from patch

I've worked up a new release of my --files-from patch. It has the following changes from the last release: New Changes: ============ - The -R option is now on by default when --files-from has been specified. The user can specify --no-relative to turn this off. - The -a (--archive) option does not imply -r when --files-from was specified. The user can still specify it manually,

Hello Regarding ownership on the destination: rsync's man page indicates that when synchronizing files to a remote host, -o implies the --numeric-ids option, which makes perfect sense aince the named users/groups may not exist on the destination host. The problem I have is that the files created on the destination still appear to be owned by the local user (server1) on the rsync

One thing that's bugged me is that some of the man page lines in the options summary are longer than 79 chars and wrap onto the next line. These are just one line summaries (detailed description appear later) so they can, and should, be terse. Here's an edited diff showing my proposed changes (and a 79 char ruler):

As threatened a while back, there are some exclude/include bugs that I'd like to see fixed in rsync. Here is the patch: http://www.blorf.net/rsync-exclude.patch This fixes the following bugs: - A non-anchored, slash-including pattern with a wildcard needs to be matched at the end of the path (e.g. "CVS/R* should match throughout the tree, not just at /CVS/R*). - A leading

If I try: rsync -lptgoD -e "ssh -i /root/.ssh/rsync-key" --verbose --exclude="/*.*" --exclude="*.xml" --include="+ */Tariff/" 192.168.1.1:/home/e-smith/files/ibays/frogs/files/dbs/ rsync lists the correct files, but if I add the destination like this: rsync -lptgoD -e "ssh -i /root/.ssh/rsync-key" --verbose --exclude="/*.*"

I've got a patch that changes f_name_to() to return an unsigned int (like snprintf() and strlcpy() do) and adds checking to ensure that we didn't overflow the name before we try to use it: http://www.blorf.net/name-overflow.patch If anyone would care to check out the following patch before I commit it, please do. ..wayne..

Hi, The patch below adds a "--ignore" option to rsync, which means "--exclude-but-dont-delete-even-if-we-specified--delete-excluded". I need this for a few tasks, the simplest of which is to have rsync resist trying to delete NetApp filers' ".snapshot" directories. The change is fairly simple (the boolean filter returns become tri-state), and works for me both

When I was working on the the hard-link change, I noticed that many of the hard-link verbose messages were getting lost. These messages get output very near the end of the transfer, and it turns out that the reason for the loss was that there are two pipes flowing from the generator and the receiver, and it was possible for the "we're all done" message to get received down the redo

I've released version 2.6.0 of rsync. Two important things to note in the new release: 1. The default remote shell is now "ssh" unless you tell the configure you want to use something else. 2. Some bug fixes in the include/exclude code, while making things work properly, have resulted in some user-visible changes for certain wildcard strings. Read the

Hi. I'm trying to accomplish the following ; 1) First, I did a rsync for a file, like this /usr/bin/rsync -lptgoD --delete --rsh=/usr/bin/ssh -R --delete-excluded -vv root@127.0.0.1:/usr/local/src/* /tmp/localhost/daily.0 If I did a ls -la to the destination dir (/tmp/localhost/daily.0/usr/local/src/README) I take ls -la /tmp/localhost/daily.0/usr/local/src/ total 60 drwxrwsr-x 2 root

Dear rsync people (particularly Wayne), I think it would be helpful for the options in the man page to be divided into sections based on which aspect of rsync's behavior they affect. Each section could also document rsync's default behavior when none of the options are given. Collecting all the possibilities for each aspect of rsync's behavior in one place would make it much easier

Please advise on rsync usage. --delete doesn?t work without recursion(--recursion). The recursion is causing huge overheads for me. My directory trees are huge. Any suggestions through which I can cut overheads. It used to work well in rsync-v2.5.5 /opt/rsync-v2.5.5/bin/rsync --delete --checksum -lptgoD --rsync-path=/opt/rsync-v2.5.5/bin/rsync --hard-links --timeout=5184000 --exclude=.snapshot

I know this has been discussed repeatedly, so might even say beaten to death, but it is a feature which I need to use. I notice Wayne had a patch to do this listed in the list archives, but I don't know what version of rsync he was patching against. What is the general opinion on using this patch for reliable rsync'ing of extremely small volumes of data of high cost, high latency comms

People, When I did: rsync -av /home/ /mntb5/ # about 4TB I got errors like: 'rsync [sender] expand file_list pointer array to xxx bytes, "did move"' with rsync hanging - after breakout on /home for writing I then get: "Read-only file system" So after unmounting and remounting /home I did: cd /home find /home/ -type d | sort >

Hi, My name is Vu Huynh. I'm currently work for Atmel Corporation. We're using Rsync v2.5.7 to rsync design kits between our remote sites. It works fine for all small kit directories. However, there is 1 BIG kit directory (But there is no file has the size of bigger than 100MB) that always gets "rsync: connection unexpectedly closed" Error. The Full Error Message

I've noticed that even if rsync has a non-zero exit code on the client that the server still reports an exit status of 0. For example, I've received an error 23 with the following output on the client-side "rsync error: some files could not be transferred (code 23) at main.c(954) [sender=2.6.9cvs]" while the server-side rsync_raw_status and rsync_exit_status were still both

On Fri, Sep 11, 2020 at 10:53:14AM +1000, Philip Rhoades via rsync <rsync at lists.samba.org> wrote: > Roland, > > > On 2020-09-10 21:27, Roland wrote: > > > with rsync hanging - after breakout on /home for writing I then get: > > > "Read-only file system" > > > > if your filesystem switches to read-only, you have a serious problem >

Using rsync 2.6.0 on both ends, I ran rsync -v --files-from files andrew@pimlott.net: . and got an error from the remote rsync. The reason is that the remote rsync is run as rsync --server --sender -vvR --files-from=- --from0 . which conflicts with a check in options.c that rsync must have two non-option arguments when --files-from is used. I tried again with the latest nightly

https://bugzilla.samba.org/show_bug.cgi?id=11656 Bug ID: 11656 Summary: Escaping broken with --files-from Product: rsync Version: 3.1.1 Hardware: x64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter:

Roland, On 2020-09-10 21:27, Roland wrote: >> with rsync hanging - after breakout on /home for writing I then get: >> "Read-only file system" > > if your filesystem switches to read-only, you have a serious problem > with your system/storage, not with rsync. > > rsync (or the workload) is simply triggering the problem. Thanks for the response . . Hmm . .