similar to: metadata in dryrun mode

> 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.

Mark II of the patch set. The first patch (dynsumlen2.patch) increments the protocol version to support per-file dynamic block checksum sizes. It is a prerequisite for varsumlen2.patch. varsumlen2.patch implements per-file dynamic block and checksum sizes. The current block size calculation only applies to files between 7MB and 160MB setting the block size to 1/10,0000 of the file length for a

Greetings, I'd like to propose a new option to rsync, which causes it to read device files as if they were regular files. This includes pipes, character devices and block devices (I'm not sure about sockets). The main motivation is cases where you need to synchronize a large amount of data that is not available as regular files, as in the following scenarios: * Keep a copy of a block

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.

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

I've run into a bug in the IO handling when reading a file. Suppose I have a file that lives on an NFS filesystem. That filesystem is NOT being exported with auth=0 permissions. So, if I try to access a file as root, it successfully opens the file, but subsequent reads fail with EACCES. This produces a destination file full of null bytes. I noticed this with 2.5.7, but checked 2.6.2 as

We use rsync to update an nfs server. After an update, we noticed that a large number of clients didn't see the updated data. It took me a while to be able to reliably reproduce this problem, but it happens on old and new versions of rysnc. It also happens across all the platforms we use here (sun/linux/netapp). This shows the problem: [Note my home directory is NFS mounted]

This is a patch to add an --rsync-exclude option to rsync-2.5.6cvs. File names in .rsync- (or .rsync+) are excluded (or included) from the file lists associated with the current directory and all of its subdirectories. This has advantages over --cvs-exclude for backing up large file systems since the .cvsignore files only apply to the current directory: unless the .cvsignore restrictions apply

I'm in the midst of coding a patch set for consideration that will bump the protocol version and have a couple of observations. The current minimum backwards-compatible protocol is 15 but we have code that checks for protocol versions as old as 12. If someone else doesn't beat me to it i'm considering cleaning out the pre-15 compatibility code. A backwards compatibility patch could

Maybe security related mails should be sent elsewhere? I didn't notice any so here it goes: sender.c:receive_sums() s->count = read_int(f); .. s->sums = (struct sum_buf *)malloc(sizeof(s->sums[0])*s->count); if (!s->sums) out_of_memory("receive_sums"); for (i=0; i < (int) s->count;i++) { s->sums[i].sum1 = read_int(f);

Hi, I have awaited the new release inorder to use the -"-partial-dir" option. But after testing it seems that it does not behave like it says on the tin. It will correctly move and rename the interrupted file to the declared directory, but it will not attempt to use it when the client attempts to rsync the file again. I have a Solaris 8 box running as a server (Matthew), and another

https://bugzilla.samba.org/show_bug.cgi?id=8308 Summary: rsync: exclude.c:532: change_local_filter_dir: Assertion `dir_depth < 4096/2+1' failed Product: rsync Version: 3.0.8 Platform: x86 OS/Version: Linux Status: NEW Severity: major Priority: P5 Component: core

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

https://bugzilla.samba.org/show_bug.cgi?id=1582 ------- Additional Comments From wayned@samba.org 2004-08-05 11:21 ------- Created an attachment (id=594) --> (https://bugzilla.samba.org/attachment.cgi?id=594&action=view) Fix problem with --dry-run (-n) This patch avoids a fatal error when using --dry-run and the destination directory does not exist on the receiver. -- Configure

In an effort to get my long-desired move-files functionality into rsync, I have created a version of my patch that runs as an extra pass at the end of the processing. This results in a simpler set of changes to rsync. I still think it would be nice to have incremental deletions during large transfers (as my first patch provides), but acceptance of this patch would relegate such quibbling to a

Updated to current cvs without the --exclude-from - patch. This patch allows specifying a --link-dest path similar to --compare-dest except that unchanged files are hard-linked to the --link-dest path instead of producing a sparse tree. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember

I was glad to see a new version of rsync because I though that it was kind of dead. :-) Anyway, I just checked and noticed that the following isn't fixed yet, or is considered a feature. When run in dry-run mode, rsync doesnt report diffs in permissions and ownership. IMHO this is not the expected and wanted behaviour, I want to see exactly what it would do without the '-n'. I have

I tried rsync 2.6.1cvs on my FreeBSD 4.X boxes. It dumps core when preserve_hard_links and backup. And SUPPORT_HARD_LINKS is true. rsync -avH --delete --backup --backup-dir=/some/backup/dir \ srchost::dir/ dir/ The core says... ------------------------------------------------------------------------ Program terminated with signal 11, Segmentation fault. #0 0x80536c0 in keep_backup

Has anybody seen this? We want to seperate the statistics out from the file list, and were using tail to grab the end of the file. the command we run is: rsync -r -a -z --partial --suffix=".backup" --exclude="*.backup" \ --stats -v /. 10.1.1.60::cds101/ > /var/log/rsync.log 2>&1 along with a number of excludes to skip the /tmp, /dev,

hi, I made some changes to generator.c : - reading data, calculating checksums and sending it to the sender now happens in one loop. - the code has become shorter - it uses less memory - 2 malloc's less that may fail - the line will be used all the time - it should be a bit faster It seems to work for me, please have a look at it. You should run "make proto" after