similar to: osx-create-time.diff

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

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, 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, I've been using rsync (OSX Tiger now Leopard) to backup my home folder daily using -a -H -A -X link-dest=dir to make incremental backups. There was a problem though since many files especially images, movies etc would be recopied each time instead of creating hard links. I have been testing the pre5 release and found that it seems to make hard links correctly for all files. I

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

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 Nicolas, On 2-Apr-09, at 6:04 PM, Nicolas Capens wrote: > Thanks for verifying this. Could you patch this or should I open a > new bug report and find a generic solution first? I don't have write access so the best I could do would be to submit a patch, and I'm crazy busy at the moment. I actually think the check I described below is fine and would fix this bug (but

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, 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 Stefanus, Thanks for verifying this. Could you patch this or should I open a new bug report and find a generic solution first? Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stefanus Du Toit Sent: woensdag 1 april 2009 18:59 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Shuffle combine On 1-Apr-09, at 12:42

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

Hello, We've run across the following missed optimization: in the attached loop (addind.c/addind-opt.ll) there's a lookup into an array (V) using an indirect index (coming from another array, WI[k]) offset by a loop- invariant base (l). The full addressing expression can be reassociated so that we add the offset l to V's base first, and then add the indirect part. This makes

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) {

On Fri, Jan 30, 2009 at 3:03 PM, Stefanus Du Toit <stefanus.dutoit at rapidmind.com> wrote: > The computation of %base then becomes loop-invariant and can be lifted out. > > What's the best way to add this optimization to LLVM? Probably the best place is LICM itself... only loop transformations are aware whether something is loop-invariant. Although, I'm not completely

The llvm-dev archives (and other llvm/clang mailing list archives) on the web don't seem to have any new messages since some time Monday night. Stefanus -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463

On 1-Apr-09, at 12:42 PM, Nicolas Capens wrote: > Hi Stefanus, > > Thanks for the info. I still think it’s a bug though. Take for > example a case where the vectors each have four elements. The values > in Mask[] can range from 0 to 7, while HLSMask only has 4 elements. > So LHSMask[Mask[i]] can go out of bounds, no? Good point! One easy way to fix this would be to use:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's my understanding that as of 3.0 rsync supports OS X ACLs and extended attributes, and that it should be possible to backup a tree from an OS X system that contains files and folders with ACLs and extended attributes to a Linux host filesystem that has both "user_xattrs" and "acl" enabled on the destination file system.

For those curious about uses of LLVM, we just officially announced our adoption of LLVM in our products: http://www.rapidmind.com/News-Nov10-08-LLVM-OpenCL.php Thanks for all the support so far on here, we look forward to continuing to work with LLVM! -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463