Re: Cannot build rsync 3.1.0 on MacOSX 10.8.5 with fileflags patch
However, attempting to build the new 3.1.0 release on a brand new Mountain Lion box with my standard 'fileflags' and 'crtimes' patches applied, make fails, reporting that 'force_change' is undeclared. Scott Lasley suggested a workaround for this: apply the 'hfs-compression' patch in addition to 'fileflags' and 'crimes' and everything works. patch -p1 patches/fileflags.diff patch -p1 patches/crtimes.diff patch -p1 patches/hfs-compression.diff ./prepare-source ./configure make sudo make install Evidently what was missing was a declaration for the force-change flag in main.c: the latter patch adds it. Looks like hfs-compression is a good patch to recommend for use on OS X installations in any case. Cheers, Tony M. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Rsync 3.1.0 failing [iobuf] on MacOSX 10.8.5 (was Re: Cannot build rsync 3.1.0 on MacOSX 10.8.5 with fileflags patch)
I got 3.1 to build all right on OS X but it won't run without stalling and lots of errors. Is it working for you or anyone else yet or have the problems come to light? Yes, now I'm using it in anger I'm seeing several fatal errors like the following (I'm syncing with a local mount point, no network access involved): need to write 129836 bytes, iobuf.out.buf is only 65532 bytes. rsync error: protocol incompatibility (code 2) at io.c(599) [sender=3.1.0] rsync: [sender] write error: Broken pipe (32) need to write 401925 bytes, iobuf.out.buf is only 65532 bytes. rsync error: protocol incompatibility (code 2) at io.c(599) [sender=3.1.0] rsync: [sender] write error: Broken pipe (32) I've rolled back to version 3.0.5 (the most recent I had installed previously) and it seems to be doing the job. Tony M. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Cannot build rsync 3.1.0 on MacOSX 10.8.5 with fileflags patch
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 just with the 'fileflags' patch alone:
patch -p1 patches/fileflags.diff
./configure
make
This generates the error:
gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -I./zlib -c main.c -o
main.o
main.c:846:6: error: use of undeclared identifier 'force_change'
if (force_change SYS_IMMUTABLE) {
^
1 error generated.
make: *** [main.o] Error 1
Building without the fileflags patch is successful.
Has anyone else noticed this behaviour?
Regards,
Tony Morton
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Passed all tests with flying colors on Mac OS X 10.4.11 - synopsis of installation and testing
I am running MacOS X 10.4.11 on PPC. The following is a synopsis of my installation procedure (as gathered from the various emails in the archive) - note that I had trouble with crtimes.diff and went back to osx-create-time.diff. Please let me know if I have included anything spurious or missed something critical (though I am pleased that everything worked)... I also get perfect results on 3.0.0 with both MacOS X 10.4.11 on PPC and MacOS X 10.5.2 on Intel, using fileflags.diff, crtimes.diff and Wayne's new fileflags-fixes.diff. I find it interesting that you have had no luck with crtimes.diff. Could you post your results? Are you applying the patches in the right order (that is, fileflags.diff followed by crtimes.diff, not vice versa)? I suspect the backup-dir-dels.diff patch is not strictly necessary, unless you actually want the functionality (as many of us do). ./prepare-source may or may not do anything, depending which source version you're using. Tony M. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: congrats!
I did a lot of tests on Tiger and Leopard with this good patch and it seems it doesn't need the --force-change options.The bbouncer test comes up clean with or without it. Is that true? Or should we use those option just in case? Should we have the option? Rob My guess is you don't need --force-change with the backup-bouncer tests because the destination volume is clean. If you were trying to replace existing files on the destination, then failing to include -- force-change would lead to problems if any files have 'uchg' or 'schg' flags set. Tony -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Passed all tests with flying colors on Mac OS X 10.4.11 - synopsis of installation and testing
I think you hit the nail on the head. I put the crtimes.diff first because I was simply swapping it in for osx-create-time.diff in Axel's email 3.0.0 test failure MacOS X 10.4.11. Upon invoking make, this error in the ordering of the patches, on my part yielded: Check the output of your 'patch' commands and make sure there are no FAILED messages. If there are, then your 'make' will probably fail unless they're resolved. If you apply fileflags.diff followed by crtimes.diff then you shouldn't see any failures - if you do then it's probably worth letting the list know. Tony M. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: fileflags.diff patch
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 I noticed there's a new nightly build - if I patch against that, I only see the first of the rejects: amorton$ patch -p1 patches/crtimes.diff patching file compat.c Hunk #1 succeeded at 44 (offset -1 lines). Hunk #2 succeeded at 62 (offset -1 lines). Hunk #3 FAILED at 136. 1 out of 3 hunks FAILED -- saving rejects to file compat.c.rej If I apply this manually, then the new rsync passes the backup-bouncer tests. I haven't tried it on a live backup yet. Tony M. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Revised flags patch
On Sat, Feb 23, 2008 at 10:41:24PM -0500, Matt McCutchen wrote: flags.diff still exists. Is that intentional? Yeah, it was briefly still available until I had time to change the crtimes patch to depend on fileflags.diff instead of flags.diff. That is now done, so the flags.diff patch is gone. Thanks Wayne. Do check that the rsync.yo in the latest nightly build resolves this little conflict: rsync.yo.rej: *** *** 1689,1695 sender's value (requires bf(--owner) and super-user privileges). it() A bf(g) means the group is different and is being updated to the sender's value (requires bf(--group) and the authority to set the group). - it() The bf(u) slot is reserved for future use. it() The bf(a) means that the ACL information changed. it() The bf(x) means that the extended attribute information changed. )) --- 1708,1714 sender's value (requires bf(--owner) and super-user privileges). it() A bf(g) means the group is different and is being updated to the sender's value (requires bf(--group) and the authority to set the group). + it() The bf(f) means that the fileflags information changed. it() The bf(a) means that the ACL information changed. it() The bf(x) means that the extended attribute information changed. )) rsync.yo from the last nightly contains sender's value (requires bf(--owner) and super-user privileges). it() A bf(g) means the group is different and is being updated to the sender's value (requires bf(--group) and the authority to set the group). it() The bf(u) slot is reserved for reporting update (access) time changes (a feature that is not yet released). it() The bf(a) means that the ACL information changed. it() The bf(x) slot is reserved for reporting extended attribute changes (a feature that is not yet released). )) Tony M. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Revised flags patch
The resulting patch is now called fileflags.diff (to match the option name): http://rsync.samba.org/ftp/rsync/patches/fileflags.diff It looks like there's a need to modify the crtimes patch consequentially: patch -p1 patches/fileflags.diff [] patch -p1 patches/crtimes.diff [] patching file log.c Hunk #1 FAILED at 644. 1 out of 1 hunk FAILED -- saving rejects to file log.c.rej [] patching file rsync.c Hunk #1 succeeded at 447 (offset 8 lines). Hunk #2 succeeded at 643 with fuzz 2 (offset 59 lines). Hunk #3 FAILED at 678. 1 out of 3 hunks FAILED -- saving rejects to file rsync.c.rej patching file rsync.h Hunk #2 FAILED at 151. Hunk #3 succeeded at 169 (offset 1 line). Hunk #4 succeeded at 640 (offset 2 lines). Hunk #5 succeeded at 648 (offset 2 lines). Hunk #6 succeeded at 903 (offset 2 lines). 1 out of 6 hunks FAILED -- saving rejects to file rsync.h.rej [] The osx-create-time patch seems clean though. Incidentally, I haven't noticed any endian issues when copying from Intel to PPC using the crtimes patch with 3.0.0pre9: might this be somehow specific to pre10? Once there's a fixed crtimes.diff for the new fileflags patch I'll give this a try. Tony M. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Rsync 3.0.0pre9 released
I've just released rsync 3.0.0pre9. We needed one last bug-fix release prior to the 3.0.0 final release, so here it is. I'm not anticipating any large changes prior to that milestone. Please help to test it to ensure that we're ready to go! Send email to the rsync mailing list with your questions, comments, bug reports, etc. Only positive comments from this end. Syncing with flags+crtimes+full metadata preservation on OSX all going as expected, both on tests with backup-bouncer and in anger between the Leopard Intel box and the Tiger PPC box. Kudos to the development team! Will be quiet now until something actually goes wrong :-) Tony M. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: various xattr problems. Was: Re: internal abbrev error! ?
That's the missing info I needed to fix the problem. There was a call in the sender that was being run when it shouldn't have in dry- run mode. The latest dev version (git, nightly, etc.) has this fixed. And it looks like all the problems I was having are now resolved. Many thanks to all! (I am now using the latest flags.diff, crtimes.diff and backup-dir- dels.diff from /ftp/rsync/patches - however I find I still need to change some instances of '--flags' to '--fileflags' in the former!) Tony M. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: creation date and OSX [performance]
My latest version of the crtimes.diff patch is now based on having the flags.diff patch applied first, so they'll work together now. You'll need to have the latest dev version of the source and the patches, though (see the downloads page for the various ways to access the source). Incidentally, it seems the latest flags.diff still has some inconsistencies between '--flags' and '--fileflags': there are some five instances of the former that need to be replaced with the latter (or should it be the other way round)? Particularly critical is line 367: args[ac++] = --flags; this appears to break fileflags transfers between local and remote hosts. I'm fairly new here - should I be filing this in Bugzilla? Is it also conceivable that the new crtimes.diff patch might get around the problem with the could not find xattr errors - anyone with a successful crtimes build care to check, or am I on completely the wrong track here? [Perhaps this is an FAQ: are the patches in /ftp/rsync/patches guaranteed to be compatible with the latest source tarball in /ftp/ rsync/nightly?] Tony -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: --exclude patterns
The shell does not strip the single quotes because they are inside double quotes. Thus, rsync is getting filter patterns containing single quotes, which would obviously prevent the filters from matching. You can just remove the single quotes, but then the shell will try to expand the wildcards when it expands $EXCLUDE. I have a similar problem. I'm trying to specify a custom per- directory filter using --filter='dir-merge .rsync-filter-m' but because the whole thing is double-quoted the filter rule arrives in single quotes. I can't simply leave out the quotes here because the --filter option only gets the first token as its argument. Is there a simple solution here? The bash man page leaves me cross- eyed. Tony M. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
OS X xattr troubles (was Re: --exclude patterns)
I have a similar problem. I'm trying to specify a custom per- directory filter using --filter='dir-merge .rsync-filter-m' but because the whole thing is double-quoted the filter rule arrives in single quotes. I can't simply leave out the quotes here because the --filter option only gets the first token as its argument. You can use an underscore instead of a space after the dir-merge. Thanks, that's solved it. Now there's a new problem I'd appreciate any help with. I've just started out with 3.0.0pre8 on OS X Leopard 10.5.1, patched according to Mike Bombich's recipe on this list at http://lists.samba.org/archive/rsync/2008-January/019618.html I have also run the backup-bouncer test as suggested (using -aHAX and --fileflags) and obtained results identical to Rob DuToit's. (Devices and fifos did not copy with their xattrs but all else was OK - this may be related to the bug Wayne opened.) However, trying a local rsync on my own home directory with -X and the destination set to a directory on a local HFS+-formatted FireWire disk (actually an iPod) immediately errors out with [sender] could not find xattr #2 for . rsync error: error in rsync protocol data stream (code 12) at xattrs.c(561) [sender=3.0.0pre8] Things seem to be OK if I omit -X to leave the xattrs out. Is this a bug or is there something up with my filesystem? (My installation's only a month old.) Tony M. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
