similar to: delete not working with multiple source directories

Dear All, I have been seeing some strange behavior using rsync 3.1.1 on OSX with the 3 standard patches applied when using the --backup and --backup-Dir options. This works as expected on 3.0.9, moving any files on dest that are not on source to the backup folder. If no changes then the backup folder is not even created. -aHAXN --fileflags --force-change --protect-decmpfs ?delete --backup

Hi All, I am have been cloning drives with several versions of xcode and am seeing very long copy times. Perhaps just because of xcode I am noticing the change. Xcode of course has many files (400,000+) many xattrs and compressed bits, decmpfs… so only natural it will be slow but sometimes upwards of 1/2 hour to a fast drive for xcode. If I turn off Xattrs (leave out the X) it flies through in

Dear All, I found a workaround for the corrupted backup app package files though there is probably a more intelligent way. When the destination is empty or missing (rather than an update) rsync.c calls make_backup and returns 1 when it encounters if (x_lstat(fname, &sx.st, NULL) < 0) return 1; the calling code in rsync.c: if ( make_backups > 0 && overwriting_basis) {

Hi All, I have had reports of problems with the -R option on OSX 10.6.4. Just tested it myself and found this odd result: When I run this "dtruss -f path/to/rsync -aHAXNR --fileflags --force-change --protect-decmpfs --stats -v /Users/astrid/Documents/main.m /Users/astrid/Desktop/rrr it produces the expected results with the relative folder paths in place

Hi Wayne, Trying out 3.1 pre 1 on OSX 10.8.4 I like the new extended stats and the ir-chunk file numbers in log. Also getting a lot of errors and most copies not completing to local disk. rsync just stalls. Standard osx build: patch -p1 <patches/fileflags.diff patch -p1 <patches/crtimes.diff patch -p1 <patches/hfs-compression.diff ./configure make rsync --fileflags --force-change

Hi All, My wrapper application for rsync 3.0.2 on osx has been working smoothly except for reports of it hanging on the last file of the transfer to a local firewire drive. We seem to have solved the mystery of the slow transfers but now, every four or five runs, it hangs at the last file to transfer and refuses to quit. Activity Monitor shows three rsync processes all at 0%CPU at

Hi, I'm trying to make a small script to get rid of Apple's TimeMachine. The aim is to backup the files of my company. I setup a MacMini with a lot of storage attached to it. The MacMini connects every once in a while to our data server (XServe) through SSH and pulls the files that need to be saved (I'm using the --link-dest option to limit the amount of files transferred, and to keep

Hi All, I'm trying a remote backup for the first time. It is between two laptops, I installed rsync 3.0.7 on both compiled patch -p1 <patches/fileflags.diff patch -p1 <patches/crtimes.diff patch -p1 <patches/crtimes-64bit.diff patch -p1 <patches/crtimes-hfs+.dif f patch -p1 <patches/hfs_compression.diff ./configure make this all works perfectly for local backups, clones

Hi All, I have been getting reports from users of backuplist+, my wrapper application for rsync (currently with build of 3.0.6), about odd behavior after updating to OS 10.6 Snow Leopard. Basically: the problem occurs backing up a directory to a local mounted network volume. Previously all worked fine but after updating to 10.6 there are reports that no files get copied and the destination fills

Hi All, I have been using rysnc 3.0.6 with Mike's rsync_3.0.6-hfs-compression_20091027.diff patch (as well as the standard osx patches) with good results. I discovered that clones done on 10.6 using this rsync cause some executable files ( the ones that are mostly compressed this way on osx ) to be damaged. I did a test twice and indeed a handful of them are damaged. They all appear to be in

Hi All, I have been reading about the HFS+ filesystem compression on Snow Leopard and how copying or cloning over system files with rsync and other tools results in them being expanded on destination. I was wondering if there was any thoughts on updating rsync to accommodate this? It is kind of a shame to the lose the benefits of the new compression. Thanks, Rob

https://bugzilla.samba.org/show_bug.cgi?id=8284 Summary: hfs-compression.diff patch incorrectly expands relative directory Product: rsync Version: 3.0.8 Platform: x64 OS/Version: Mac OS X Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org

Are there any patches (or planned updates) to rsync v3.0.6 to handle the HFS+ File Compression that Apple introduced with Snow Leopard?

Hello everyone! FOREWORD: I respect your time and resources, I hope to not bother people on this mailinglist! To my defense: This question is far easier towards humans than to mailinglist and web search-engines as the search terms in relation to each other are highly in-causal or paradoxical, and hence lead to poor results. Of course the manpage was the first place where I looked

Hi anybody! I'm not shure if this really is a rsync problem, it might also be a shell issue. But hopefully, someone has a hint for me ;-) I'm using rsync 3.0.9 on two OS X Servers (FreeBSD) to synchronize several folders between both servers (2-way-sync). Works fine, with one exception: One of the directories to be sync'd contains a whitespace in its pathname, and this one only

Returning to this list after a long hiatus: rsync 3 has been working very well for me for many years, as a supplementary backup tool for MacOSX. However, attempting to build the new 3.1.0 release on a brand new Mountain Lion box with my standard 'fileflags' and 'crimes' patches applied, make fails, reporting that 'force_change' is undeclared. In fact, the problem occurs

https://bugzilla.samba.org/show_bug.cgi?id=8019 Summary: Various improvements to the fileflags patch Product: rsync Version: 3.0.8 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: mike at bombich.com

Hi, first of all, sorry for taking so long. Unfortunately, some other tasks kept coming up. Anyway, attached is the version of the flags patch, that is based on the one I'm using with 2.6.9. It is against the rsync-3.0.0pre9 release. I've included the option name change from the repository, so the option is now called --fileflags. Improved from the previously distributed version is the

Hi All, I just tried (on OS10.5.2) the new fileflags.diff patch patch -p1 <patches/fileflags.diff patch -p1 <patches/crtimes.diff (see result below- I fixed the rej's ) then ./configure make then tried it out but it isn't copying the creation dates now.... just wondering if I missed something .. Rob D robert-dutoits-powerbook-g4-15:rsync-3.0.0pre10 astrid$ patch -p1

Looking at http://rsync.samba.org/ftp/rsync/patches/fileflags.diff -- It looks like the changes from fileflags-fixes.diff patch were applied to the patch from http://rsync.samba.org/ftp/rsync/rsync-patches-3.0.0.tar.gz , but this entire chunk of the that original diff file was lost: > diff -up a/config.h.in b/config.h.in > --- a/config.h.in > +++ b/config.h.in > @@ -64,6 +64,9 @@