similar to: [Bug 3358] New: rsync chokes on large files

https://bugzilla.samba.org/show_bug.cgi?id=5201 Summary: Rsync lets user corrupt dest by applying non-inplace batch in inplace mode Product: rsync Version: 3.0.0 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo:

https://bugzilla.samba.org/show_bug.cgi?id=13071 Bug ID: 13071 Summary: [PATCH] Allow --partial-dir with --inplace Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter:

https://bugzilla.samba.org/show_bug.cgi?id=13423 Bug ID: 13423 Summary: Checksum option does not work as expected when append-verify is used Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core

https://bugzilla.samba.org/show_bug.cgi?id=5246 Summary: rsync fails to transfer some files Product: rsync Version: 2.6.9 Platform: Other OS/Version: Mac OS X Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: david-bo@dsv.su.se

https://bugzilla.samba.org/show_bug.cgi?id=7778 Summary: --inplace does extra WRITE operations Product: rsync Version: 3.0.7 Platform: Other OS/Version: Linux Status: NEW Severity: minor Priority: P3 Component: core AssignedTo: wayned at samba.org ReportedBy: ildar at altlinux.ru

https://bugzilla.samba.org/show_bug.cgi?id=8990 Summary: --append-verify doesn't spot file differences, even with --checksum Product: rsync Version: 3.0.9 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org

The attached patch provides an additional check for the checksumming mode to ensure that a file that is actually written out to disk can be read back and has the same MD4 sum as the file on at the originating location. Regards, Nick. -------------- next part -------------- *** rsync-2.6.6pre1/receiver.c 2005-04-14 02:42:13.000000000 +0100 --- rsync-new/receiver.c 2005-07-26

Hi, how does rsync work if it compares two very huge files on two distinct hosts (rsync uses a networked connection, via SSH)? Some observation seems to indicate, that rsync first reads (and checksums?) the remote (destination) side, then, if finished, it reads (and checksums?) the local (source) side and then starts transferring the delta if done with the comparison of these two files on both

Hello, i`m using rsync to sync large virtual machine files from one esx server to another. rsync is running inside the so called "esx console" which is basically a specially crafted linux vm with some restrictions. the speed is "reasonable", but i guess it`s not the optimum - at least i don?t know where the bottleneck is. i`m not using ssh as transport but run rsync in

ZFS documentation lists snapshot limits on any single file system in a pool at 2**48 snaps, and that seems to logically imply that a snap on a file system does not require an update to the pool?s currently active uberblock. That is to say, that if we take a snapshot of a file system in a pool, and then make any changes to that file system, the copy on write behavior induced by the changes will

https://bugzilla.samba.org/show_bug.cgi?id=3415 Summary: -R and --delete cause --delete to be ignored Product: rsync Version: 2.6.6 Platform: Other OS/Version: Windows 2000 Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: dietmar@zlabinger.at

https://bugzilla.samba.org/show_bug.cgi?id=13645 Bug ID: 13645 Summary: Improve efficiency when resuming transfer of large files Product: rsync Version: 3.0.9 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: core Assignee:

https://bugzilla.samba.org/show_bug.cgi?id=4128 Summary: ignore-times with link-dest behaves unexpected / sematics not clear Product: rsync Version: 2.6.8 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org

My job, rsync -auv --exclude ".snapshot" --delete --safe-links /NFSvol/bam1/vg1/home1 /Volumes/xraid3/bam1/vol1/ >/var/local/log/bam1home1.log 2>&1 is several times with the following message, Invalid checksum length 1913126912 rsync error: protocol incompatibility (code 2) at /SourceCache/rsync/rsync-20/rsync/sender.c(59) rsync: writefd_unbuffered failed to write 103

We are using rsync to transfer Oracle redo logs from one system to another over a WAN/VPN. The problem we are having is that 1 out of about 500 or so files sent is corrupted. The receiving Oracle server produces a message like this: --- Specify log: {<RET>=suggested | filename | AUTO | CANCEL} ORA-00283: recovery session canceled due to errors ORA-00368: checksum error in redo log block

https://bugzilla.samba.org/show_bug.cgi?id=4079 Summary: rsync fails with --inplace, --link-dest and --no-whole- file Product: rsync Version: 2.6.8 Platform: x86 OS/Version: Linux Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned@samba.org

https://bugzilla.samba.org/show_bug.cgi?id=13735 Bug ID: 13735 Summary: Synchronize files when the sending side has newer change times while modification times and sizes are identical on both sides Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW

https://bugzilla.samba.org/show_bug.cgi?id=8177 Summary: Problems with big sparsed files Product: rsync Version: 3.0.8 Platform: x64 OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: joluinfante at gmail.com

https://bugzilla.samba.org/show_bug.cgi?id=13320 Bug ID: 13320 Summary: file contents cause rsync to fail (with certains args and dir structure) Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core

https://bugzilla.samba.org/show_bug.cgi?id=13820 Bug ID: 13820 Summary: rsync is not preserving ACLs Product: rsync Version: 3.1.3 Hardware: x64 OS: Linux Status: NEW Severity: major Priority: P5 Component: core Assignee: wayne at opencoder.net Reporter: dinesh.k at