Making rsync compile under Mac OS X 10.3.9 with extended attributes
Somebody knows if it's possible to compile rsync (version 3 would be great, but can be 2.6.x) under Mac OS X 10.3.9 with extended attributes? Under OS 10.3.9 the Apple shipped rsync have not yet the -E argument option. RsyncX have a double free bug that is annoying. Q rsync 2.6.6 with extended attributes binary only works on 10.4 and above. I have tried to compile rsync from source but the problem I found is that the xattr patch seems to need the acl patch. But 10.3 doesn't have the ACL support so doesn't provides the expected headers and the make command fails. I will try out 2 more things: 1) Ignore the instructions of xattr patch and do not apply the acl patch before xattr (but if those instructions are there, I'm almost sure it's for a good reason...) 2) Try to get a patched rsync via fink or darwinport But I would appreciate any help or feedback about compiling a extended- attribute rsync on 10.3.9, even more if it's the last version (meaning that rsync could still progress on those macs and the development is not closed for them). Best regards, Vitorio Machado-- 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: Making rsync compile under Mac OS X 10.3.9 with extended attributes
Sorry about spamming the list. This update is just to say that I have tested solutions 1 and 2 and there is no solution: 1) If I configure with --disable-acl --enable-xattr, configure is OK but make can't compile xattr.c because it seems linked to ACL code... 2) The versions disponible at darwinport and fink are unpatched (without extended-attributes) or just avaliable for 10.4+. So I would really need to compile it from source, if someone have a magic argument like --compile-on-10.3-with-xattr-without-acl... Best regards, Vitorio Machado Le 24 janv. 08 à 13:25, Vitorio Machado a écrit : Somebody knows if it's possible to compile rsync (version 3 would be great, but can be 2.6.x) under Mac OS X 10.3.9 with extended attributes? Under OS 10.3.9 the Apple shipped rsync have not yet the -E argument option. RsyncX have a double free bug that is annoying. Q rsync 2.6.6 with extended attributes binary only works on 10.4 and above. I have tried to compile rsync from source but the problem I found is that the xattr patch seems to need the acl patch. But 10.3 doesn't have the ACL support so doesn't provides the expected headers and the make command fails. I will try out 2 more things: 1) Ignore the instructions of xattr patch and do not apply the acl patch before xattr (but if those instructions are there, I'm almost sure it's for a good reason...) 2) Try to get a patched rsync via fink or darwinport But I would appreciate any help or feedback about compiling a extended-attribute rsync on 10.3.9, even more if it's the last version (meaning that rsync could still progress on those macs and the development is not closed for them). Best regards, Vitorio Machado -- 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.0pre8 and Mac OS X
I see now that *Apple's* iconv does have the necessary utf8mac encoding. See: http://code.google.com/p/macfuse/issues/detail?id=139 http://libiconv.darwinports.com/ So just pass --iconv=utf8mac,iso885915 when the Mac is sending and --iconv=iso885915,utf8mac when it is receiving, and the problem should go away. Matt On Thu, 2008-01-24 at 07:54 +0100, Rudolf E. Reiber wrote: Hi Matt, thanks for your answer. Are the developers working at this problem? So, can I wait for the solution und in the meantime have a little more traffic on the line? Rudolf Am 24.01.2008 um 05:28 schrieb Matt McCutchen: A question to the developers: do you see any solution to this problem? Perhaps a --icont=utf8mac, iso885915 ? Precisely. We need an iconv encoding name for the form of UTF-8 that the Mac likes, and none of the existing encodings in the iconv on my computer fit the bill. Another option is store the umlaut-named files on a filesystem other than HFS+ on the Mac. Matt -- 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: Making rsync compile under Mac OS X 10.3.9 with extended attributes
On Thu, 2008-01-24 at 13:25 +0100, Vitorio Machado wrote: Somebody knows if it's possible to compile rsync (version 3 would be great, but can be 2.6.x) under Mac OS X 10.3.9 with extended attributes? I have tried to compile rsync from source but the problem I found is that the xattr patch seems to need the acl patch. But 10.3 doesn't have the ACL support so doesn't provides the expected headers and the make command fails. In rsync 3, support for preserving acls and xattrs is in the trunk and the acls and xattrs patches just add acl and xattr protocol compatibility with older versions of rsync. Thus, you probably don't need to apply either patch. Try compiling rsync 3.0.0pre8 without patches, and if you still run into problems, post the exact error message(s). Matt -- 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.0pre8 and Mac OS X
Please keep this on the rsync list. On Thu, 2008-01-24 at 18:32 +0100, Rudolf E. Reiber wrote: I am sorry, but when I apply the --iconv=utf8mac,iso885915 option, the rsync compleately fails. to compile some patches or do some other things in order getting utf8mac to work? Or is this feature built in Rsync 3.0.0pre8? Support for encodings such as utf8mac is determined by the Mac's libiconv, not by rsync. You need to install a libiconv that supports the utf8mac encoding (check that utf8mac is listed when you run iconv --list) and then build rsync against that libiconv. It looks like your best bet is the MacPorts libiconv described here: http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/libiconv/Portfile In fact, rsync 3.0.0pre8 itself appears to be available through MacPorts: http://trac.macports.org/projects/macports/browser/trunk/dports/net/rsync-devel/Portfile Matt Am 24.01.2008 um 16:11 schrieb Matt McCutchen: I see now that *Apple's* iconv does have the necessary utf8mac encoding. See: http://code.google.com/p/macfuse/issues/detail?id=139 http://libiconv.darwinports.com/ So just pass --iconv=utf8mac,iso885915 when the Mac is sending and --iconv=iso885915,utf8mac when it is receiving, and the problem should go away. -- 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.0pre8 released
On Sat, 2008-01-12 at 11:19 -0800, Wayne Davison wrote: I've just released rsync 3.0.0pre8. I have finally gotten around to making RPMs of rsync 3.0.0pre8: http://mattmccutchen.net/rsync/#rsync-packages Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[PATCH] Fix spelling/grammar in NEWS.
--- Let's try submitting a patch the git way! NEWS | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index 0f7c634..9258e6b 100644 --- a/NEWS +++ b/NEWS @@ -11,7 +11,7 @@ Changes since 2.6.9: an implied dir be duplicated as a symlink, you should specify the transfer of the symlink and the transfer of the referent directory as separate args. (See also --keep-dirlinks and --no-implied-dirs.) - Also, exclude rules no longer have a partial affect on implied dirs. + Also, exclude rules no longer have a partial effect on implied dirs. - Requesting a remote file list without specifying -r (--recursive) now sends the -d (--dirs) option to the remote rsync rather than sending -r @@ -22,7 +22,7 @@ Changes since 2.6.9: - In --dry-run mode, the last line of the verbose summary text is output with a (DRY RUN) suffix to help remind you that no updates were made. -- A writable rsync daemon that disables use chroot now defaults to a +- A writable rsync daemon with use chroot disabled now defaults to a symlink-munging behavior designed to make symlinks safer while also allowing absolute symlinks to be stored and retrieved. This also has the effect of making symlinks unusable while they're in the daemon's @@ -36,8 +36,8 @@ Changes since 2.6.9: --backup-dir, --temp-dir, and --files-from. - If a file's data arrived successfully on the receiving side but the - rename of the tempory file to the destination file failed AND the - --remove-souce-files (or the deprecated --remove-sent-files) option + rename of the temporary file to the destination file failed AND the + --remove-source-files (or the deprecated --remove-sent-files) option was specified, rsync no longer erroneously removes the associated source file. @@ -137,7 +137,7 @@ Changes since 2.6.9: - Added the --acls (-A) option to preserve Access Control Lists. This is an improved version of the prior patch that was available, and it even supports OS X ACLs. If you need to have backward compatibility with old, - acl-patched versions of rsync, apply the acls.diff file from the patches + ACL-patched versions of rsync, apply the acls.diff file from the patches dir. - Added the --xattrs (-X) option to preserver extended attributes. This is -- 1.5.4.rc3.15.g4bbc -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 4037] Rsync should obey --keep-dirlinks when searching basis dirs
https://bugzilla.samba.org/show_bug.cgi?id=4037 --- Comment #2 from [EMAIL PROTECTED] 2008-01-24 13:28 CST --- Note that, in the absence of a proper fix for this issue, symlink munging in the destination can prevent surprises like the one seen in comment #1. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
how to know the detail about a partial transfer?
Hi All We always run rsync with --files-from and sometime it gets a error code 23, partial transfer. is it possible to find out what files are not transferred without check the error message by human eye(since we want to do it in a script)? Thanks. -- Ming Zhang @#$%^ purging memory... (*!% http://blackmagic02881.wordpress.com/ http://www.linkedin.com/in/blackmagic02881 -- 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: how to know the detail about a partial transfer?
On Thu, 2008-01-24 at 18:00 -0500, Ming Zhang wrote: We always run rsync with --files-from and sometime it gets a error code 23, partial transfer. is it possible to find out what files are not transferred without check the error message by human eye(since we want to do it in a script)? Not easily, since the error messages indicating different kinds of failure for a given file don't follow a standard pattern. Some approaches: 1. Write a humongous sed script to match all the error messages and extract the filenames. 2. Use --log-file, and look at what files are *not* itemized in the log. (Most failures, but evidently not certain attribute-related failures, will cause a file to be omitted from the log.) 3. The most pragmatic approach: rerun rsync with --dry-run and look at which files are still itemized as different. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[PATCH] Report chmod failure when --executability is on.
---
syscall.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/syscall.c b/syscall.c
index 4369c6e..39554e9 100644
--- a/syscall.c
+++ b/syscall.c
@@ -34,6 +34,7 @@ extern int am_root;
extern int read_only;
extern int list_only;
extern int preserve_perms;
+extern int preserve_executability;
#define RETURN_ERROR_IF(x,e) \
do { \
@@ -167,7 +168,7 @@ int do_chmod(const char *path, mode_t mode)
#endif
} else
code = chmod(path, mode CHMOD_BITS);
- if (code != 0 preserve_perms)
+ if (code != 0 (preserve_perms || preserve_executability))
return code;
return 0;
}
--
1.5.4.rc3.15.g4bbc
--
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: how to know the detail about a partial transfer?
On Thu, 2008-01-24 at 20:20 -0500, Matt McCutchen wrote: On Thu, 2008-01-24 at 18:00 -0500, Ming Zhang wrote: We always run rsync with --files-from and sometime it gets a error code 23, partial transfer. is it possible to find out what files are not transferred without check the error message by human eye(since we want to do it in a script)? Not easily, since the error messages indicating different kinds of failure for a given file don't follow a standard pattern. Some approaches: is it possible to change those error messages into a standard pattern? 1. Write a humongous sed script to match all the error messages and extract the filenames. 2. Use --log-file, and look at what files are *not* itemized in the log. (Most failures, but evidently not certain attribute-related failures, will cause a file to be omitted from the log.) 3. The most pragmatic approach: rerun rsync with --dry-run and look at which files are still itemized as different. i am trying to do 1 now and think 3 is better. but since rsync daemon know which file(s) are not transferred, can rsync daemon pass these information back to rsync client and print it out? Matt -- Ming Zhang @#$%^ purging memory... (*!% http://blackmagic02881.wordpress.com/ http://www.linkedin.com/in/blackmagic02881 -- 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: how to know the detail about a partial transfer?
On Thu, 2008-01-24 at 20:56 -0500, Ming Zhang wrote: Not easily, since the error messages indicating different kinds of failure for a given file don't follow a standard pattern. Some approaches: is it possible to change those error messages into a standard pattern? Yes, it would be possible, but it would require going through and reformatting each of the 77 FERROR_XFER messages individually and would make a few of them less readable (e.g., link A = B failed would become B: link from A failed). Another option would be to print an additional failed to propagate B message after a failure of any kind on file B, and your script could just match those messages. i am trying to do 1 now and think 3 is better. but since rsync daemon know which file(s) are not transferred, can rsync daemon pass these information back to rsync client and print it out? It's not clear to me what you are proposing. First, are you referring to a push or a pull? Matt -- 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: how to know the detail about a partial transfer?
On Thu, 2008-01-24 at 21:25 -0500, Matt McCutchen wrote: On Thu, 2008-01-24 at 20:56 -0500, Ming Zhang wrote: Not easily, since the error messages indicating different kinds of failure for a given file don't follow a standard pattern. Some approaches: is it possible to change those error messages into a standard pattern? Yes, it would be possible, but it would require going through and reformatting each of the 77 FERROR_XFER messages individually and would make a few of them less readable (e.g., link A = B failed would become B: link from A failed). Another option would be to print an additional failed to propagate B message after a failure of any kind on file B, and your script could just match those messages. additional messages could be better in this case. i am trying to do 1 now and think 3 is better. but since rsync daemon know which file(s) are not transferred, can rsync daemon pass these information back to rsync client and print it out? It's not clear to me what you are proposing. First, are you referring to a push or a pull? push from rsync client to rsync daemon. one example is in receiver.c line 652, rsync daemon try to open/create a file but failed, so rsync daemon here know exact which file it is working on, so if rsync daemon can pass this info back to rsync client, rsync client can save this to a file. Matt -- Ming Zhang @#$%^ purging memory... (*!% http://blackmagic02881.wordpress.com/ http://www.linkedin.com/in/blackmagic02881 -- 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.0pre8 and Mac OS X
Hi Matt, thanks for your great help! A look onto iconv --list told me, that the only mistake was a miss- spelling. I had to write --iconv=UTF8-MAC,ISO-8859-15 and everything worked very well! cheers to You! I think, that a hint to iconv --list in the rsync man-page would be graet Rudolf Am 24.01.2008 um 19:18 schrieb Matt McCutchen: Please keep this on the rsync list. On Thu, 2008-01-24 at 18:32 +0100, Rudolf E. Reiber wrote: I am sorry, but when I apply the --iconv=utf8mac,iso885915 option, the rsync compleately fails. to compile some patches or do some other things in order getting utf8mac to work? Or is this feature built in Rsync 3.0.0pre8? Support for encodings such as utf8mac is determined by the Mac's libiconv, not by rsync. You need to install a libiconv that supports the utf8mac encoding (check that utf8mac is listed when you run iconv --list) and then build rsync against that libiconv. It looks like your best bet is the MacPorts libiconv described here: http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/libiconv/Portfile In fact, rsync 3.0.0pre8 itself appears to be available through MacPorts: http://trac.macports.org/projects/macports/browser/trunk/dports/net/rsync-devel/Portfile Matt Am 24.01.2008 um 16:11 schrieb Matt McCutchen: I see now that *Apple's* iconv does have the necessary utf8mac encoding. See: http://code.google.com/p/macfuse/issues/detail?id=139 http://libiconv.darwinports.com/ So just pass --iconv=utf8mac,iso885915 when the Mac is sending and --iconv=iso885915,utf8mac when it is receiving, and the problem should go away. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
