search for: rdutoit

Hi All, So far the tests show the universal build of rsync 3.0 (using lipo) to be indeed universal. Metadata tests all come up clean on OSX Tiger and Leopard, both PPC and Intel architectures. Some people asked for the compiled binary so I put it here: http://rdutoit.home.comcast.net/~rdutoit/dir/lip.zip Thanks, Rob D

Hello All, I am having an interesting issue where using the command ?rsync ?avP ?e ssh? seems to want to bail out on filesystems that have more than about 1.2 million files. Using that same command on smaller filesystems works like a charm! The server is rsync 2.6.8 protocol 29 and the destination is rsync 2.6.3 protocol 28. The server is Fedora Core 4 and the client is Mac OS 10.5.2. What am

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, hi Mike, I am just building 3.0.8 on osx 10.6.6 and mike's hfs_compression.diff is failing. Am I missing something? Thanks, Rob patch -p1 <patches/fileflags.diff patch -p1 <patches/crtimes.diff patch -p1 <patches/crtimes-64bit.diff ( this says previously applied?) patch -p1 <patches/crtimes-hfs+.diff but for patch -p1 <patches/hfs_compression.diff patching file

Just chiming in here, I haven’t read all the previous posts so may be repeating… Mike Bombich has a good piece on benchmarks for various source/destination scenarios with rsync. https://bombich.com/kb/ccc3/how-long-should-clone-or-backup-take Note that copying to sparsebundle on local media is as fast as to local disk. Sparsebundle is a mac filesystem whereas NAS is not so certain file

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

...+ char *buf = get_backup_name(fname); + + if (!buf) + return 0; + /* Try a hard-link or a rename first. Using rename is not atomic, but * is more efficient than forcing a copy for larger files when no hard- * linking is possible. */ On Jan 16, 2015, at 9:41 AM, Robert DuToit <rdutoit at comcast.net> wrote: > 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...

Hi All, Well, we compiled pre9 on an intel Mac running Tiger and now it does work on the machine. I need to see if that will now work on a PPC mac though. Hopefully it will but I am wondering if there is a way to compile and make a universal binary rsync for the Mac that will run on both, from my PPC Mac. Itried that yesterday with patch -p1 <patches/flags.diff patch -p1

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

Hi All, I am new to the list. I have been using the Tiger rsync version in a small wrapper application for command line backup tools and am trying out the rsync-3.0.0pre4 release. Looks good so far. I just tried the patch osx-create-time.diff and it works! But when I tried to apply the two additional patch fixes I ran into problems and would appreciate any help there. The first patch

Hi, Before I go any further about OSX creation dates etc. I just discovered that the pre5 release doesn't work on OSX Tiger. I got this message in the rsync progress: dyld: Library not loaded: /usr/lib/libiconv.2.dylib Reason: Incompatible library version: rsync requires version 7.0.0 or later, but libiconv.2.dylib provides version 5.0.0 Is there any way around this? I really need

Hi All, I have a client and we are trying to create a backup for several folders on OSX 10.4.11 with rsync 3.0.0pre9. One folder copies fine but the other three generate this error and I am stumped. using: rsync -aHAX --fileflags --crtimes -v we get; sending incremental file list rsync: writefd_unbuffered failed to write 82 bytes [generator]: Broken pipe (32) rsync error: error in

Hi Again, Sorry to keep posting about this. There seems to be a lot of confusion trying to get compatibility with various Mac architectures and OS. Sven Peters was able to compile on an intel Mac running leopard using >patch -p1 <patches/flags.diff >patch -p1 <patches/crtimes.diff >./configure CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch

Hi All, I promise I won't bug you anymore about this but I did find that the compiled universal binary on rsync3.0.pre10 does preserve creation dates across platforms with the old osx-create-time.diff patch but not with the crtimes patch. If anyone has a clue about this I would be happy to fix it. Thanks again Rob D PS so close!

Hi All, A quick question. I tried --iconv=. but it didn't seem to work for my friend with umlautes in his file names. In the archives I found mention of a patch iconv.diff. Is that necessary or is it now included in the source - it wasn't in my latest atches directory? Rob

Hi All, I've been off list for a while and just got around to building rsync 3.0.6 on Mac OSX 10.6 intel core 2 duo machine. It runs great on similar machines but someone just said it won't for their OSX 10.6 intel core duo and returns an error: rsync Bad CPU type in executable. I check the file and it says: rsync: Mach-O 64-bit executable x86_64 my older builds all

Hi All, I don't know if this has been discussed here but creation dates are nto being preserved on OSX 10.6.1 in 64 bit mode. Rare of course, the folks that are using 64 but I am getting reports. I built in 64 with the usual crtimes and fileflags patches. Otherwise works like a dream and, in 64, is unbelievably Fast! Thanks, Rob

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

Hi All, I reported a ways back about strange file replication via rsync copying to an OSX 10.6.3 local network volume. Hidden dot files such as .DS-Store and other "dot" files on OSX were copied to the local volume with appended names indicating that the temp files created by rsync were ending up on the destination instead of the originals, often by the thousands. Ok, so I am back on

Hi All, I have a situations where I need output to a file and normally would just append ?&>output.log? to the rsync command line but can?t do that in this situation and need to run rsync with just the args via nstask. I tried the internal --log-file=File option which works except it outputs very verbosely and not the usual (xfer#8, to-check=1115/1125) output I need to parse. I don?t