Re: Making rsync compile under Mac OS X 10.3.9 with extended attributes
v0.5 is out! Changelog: 0.5 - Corrected path parser bug that would break if part of the path was an alias and not a folder. Corrected the fifos, block and character devices detection. 0.4 - Rewrited getxattr, setxattr to don't use getattrlist/setattrlist Corrected a bug on path2fsref where non-ASCII characters bugged Rewrited listxattr to better handle fifos, block and character devices PS: This patch goes fine with rsync 3.0.0pre10 0.3 - Corrected a bug that makes files with resource fork invisible 0.2 - Corrected a pointer bug in sys_lgetxattr and sys_lsetxattr Corrected a bracket problem in sys_llistxattr 0.1 - First alpha compiling version There is still a strange little bug: Running sudo ./rsync -aHXN --fileflags /Volumes/Src /Volumes/Dst/80-rsync-test for the first time gives an error rsync: failed to set times on /Volumes/Dst/80-rsync-test/Src/60-bsd-flags/dir-with-flags: Operation not permitted (1) The dir dir-with-flags it's created and appears to have the good times: iLaG:~/Desktop/rsync-3.0.0pre10 patched lag$ /Developer/Tools/GetFileInfo /Volumes/Dst/80-rsync-test/Src/60-bsd-flags/dir-with-flags directory: /Volumes/Dst/80-rsync-test/Src/60-bsd-flags/dir-with-flags attributes: avbstcLinmed created: 02/17/2008 21:58:36 modified: 02/17/2008 21:58:36 iLaG:~/Desktop/rsync-3.0.0pre10 patched lag$ /Developer/Tools/GetFileInfo /Volumes/Src/60-bsd-flags/dir-with-flags directory: /Volumes/Src/60-bsd-flags/dir-with-flags attributes: avbstcLinmed created: 02/17/2008 21:58:36 modified: 02/17/2008 21:58:36 If I rerun the rsync it makes no error. If I run rsync for the first time without -X option it makes no error neither. What's strange is that the time setting have nothing to do with my mods. What I've seen is that crtimes patch uses getattrlist/setattrlist that I'm avoiding because it doesn't have the same behaviour on 10.3 and 10.4 (man getattrlist doesn't even exist on 10.3, the function was undocumented). But I don't know why it doesn't bug running without -X, as crtimes.diff is still active. There is maybe a bug mixing Carbon and getattrlist calls. I'm attaching the verbose log of the operations before the error. And the patch, of course! Vitorio recv_files(Src/60-bsd-flags/file-with-flags) got file_sum sys_llistxattr(Src/60-bsd-flags/.file-with-flags.CqNyUX, 0x2800400, 1024); fsreffrompath(Src/60-bsd-flags/.file-with-flags.CqNyUX, 0xbfffcc00); PWD=/Volumes/Dst/80-rsync-test name=.file-with-flags.CqNyUX list lenght=21, list content: com.apple.FinderInfo sys_lsetxattr(Src/60-bsd-flags/.file-with-flags.CqNyUX, com.apple.FinderInfo, 32); value= fsreffrompath(Src/60-bsd-flags/.file-with-flags.CqNyUX, 0xbfffca80); PWD=/Volumes/Dst/80-rsync-test name=.file-with-flags.CqNyUX set modtime of Src/60-bsd-flags/.file-with-flags.CqNyUX to (1203281916) Sun Feb 17 21:58:36 2008 renaming Src/60-bsd-flags/.file-with-flags.CqNyUX to Src/60-bsd-flags/file-with-flags touch_up_dirs: Src/60-bsd-flags (11) set modtime of Src/60-bsd-flags to (1203281916) Sun Feb 17 21:58:36 2008 touch_up_dirs: Src/60-bsd-flags/dir-with-flags (22) set modtime of Src/60-bsd-flags/dir-with-flags to (1203281916) Sun Feb 17 21:58:36 2008 recv_files(Src/60-bsd-flags/dir-with-flags) sys_llistxattr(Src/60-bsd-flags/dir-with-flags, 0x2800400, 1024); fsreffrompath(Src/60-bsd-flags/dir-with-flags, 0xbfffcc60); PWD=/Volumes/Dst/80-rsync-test name=dir-with-flags list lenght=21, list content: com.apple.FinderInfo sys_lsetxattr(Src/60-bsd-flags/dir-with-flags, com.apple.FinderInfo, 32); value= fsreffrompath(Src/60-bsd-flags/dir-with-flags, 0xbfffcae0); PWD=/Volumes/Dst/80-rsync-test name=dir-with-flags set modtime of Src/60-bsd-flags/dir-with-flags to (1203281916) Sun Feb 17 21:58:36 2008 rsync: failed to set times on /Volumes/Dst/80-rsync-test/Src/60-bsd-flags/dir-with-flags: Operation not permitted (1) recv_files(Src/70-extended-attrs) rsync10.3xattr_supportv0.5.diff Description: Binary data -- 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
@Rob: Yes, rsync needs a newer version of autoconf than the one installed. But you can download and compile it without problem: 1) get the sources from http://ftp.gnu.org/gnu/autoconf/autoconf-2.61.tar.gz 2) unpack the sources 3) Open a Terminal and run the command: cd drop the autoconf source folder here 4) run the command: ./configure make sudo make install This combo makes everything you need and puts the autoconf in the right place /usr/local 5) You need to say your system to use the newer autoconf by default. - To do it once (the config will be active on the Terminal windows the command was entered until the window is closed, run the command: export PATH=/usr/local/bin:$PATH - To do this automatically for all Terminal windows opened (what I recommend), run the command: echo export PATH=/usr/local/bin:$PATH .profile Note that this won't do any changes in the current Terminal window. You have to close and reopen it or to apply both first and second method to have the right PATH. 6) You can verify the PATH running this command: iLaG:~/Desktop/rsync-3.0.0pre10 patched lag$ echo $PATH /usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin Don't worry if your PATH isn't exactly the same, what's important for autoconf is only that it begin with /usr/local/bin: Anyways, I've put the binarie compiled on 10.3.9 PPC G3 that should work also on lower systems here http://shared.and.free.fr/rsync%203.0.0pre10%20patched%20v0.4.zip @Matt: No, it makes an empty directory Src but refuses to list attrs of anything on it claiming that one element of the path is not a folder... What's true. Maybe I should be more flexible with alias in the name? iLaG:~/Desktop/rsync-3.0.0pre10 patched lag$ sudo ./rsync -aHXN --fileflags /Volumes/Src /Volumes/Dst/80-rsync-test/ Password: rsync: get_xattr_names: llistxattr(Src/.DS_Store,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/.Trashes,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/00-basic-permissions,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/05-timestamps,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/10-symlinks,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/15-symlink-ownership,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/20-hardlinks,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/30-resource-forks,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/40-finder-flags,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/45-finder-locks,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/50-creation-date,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/60-bsd-flags,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/70-extended-attrs,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/80-access-control-lists,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/90-fifo,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/95-devices,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/99-combo-tests,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/bbouncer-vol,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/Desktop DB,1024) failed: Not a directory (20) rsync: get_xattr_names: llistxattr(Src/Desktop DF,1024) failed: Not a directory (20) rsync error: some files could not be transferred (code 23) at main.c(1060) [sender=3.0.0pre10] iLaG:~/Desktop/rsync-3.0.0pre10 patched lag$ @Wayne: Thanks for the correction! I've another small warning: clientname.c line 268 rprintf(FLOG, %s: too short sockaddr_in6; length=%d\n, fn, ai-ai_addrlen); Length is a %d (int) but ai-ai_addrlen is a ssize_t (long int). In many CPUs int and long int are both 32 bits so this is not a big deal, but putting %ld instead of %d makes gcc happy :) -- 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-02-21 at 23:59 +0100, Vitorio Machado wrote: This version copies the test files of backup bouncer disk image except for some tricky files, like fifos. Great news! There is an issue that I don't know if it's a known bug: If I run: sudo ./rsync -aHXN --fileflags /Volumes/Src/ /Volumes/Dst/80-rsync-test/ It goes all fine, but sudo ./rsync -aHXN --fileflags /Volumes/Src /Volumes/Dst/80-rsync-test/ does not. It's maybe normal because Src, as a mount point, is seen as an alias, so it refuse to go deeper, as we have NO_FOLLOW options all into the code. It's not very clear to me, can somebody explain better this point saying if it's normal/a bug/a known issue? If /Volumes/Src is an alias, Mac OS X's POSIX filesystem API may be exposing it to rsync as a zero-length regular file. See if the second command creates a zero-length regular file at /Volumes/Dst/80-rsync-test/Src . 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
Hello Rob (and who else may be interested in news about 10.3 support patch), 1) Make sure you have a fresh copy of rsync (3.0.0pre9 for the moment) when patching and compiling. Patching an already patched source code won't do anything good. 2) If you removes the X option is the same as using normla rsync. It won't copy any extended attr. 3) I don't know exactly what you mean by no luck, but I tested the backup bouncer. It ends up in a 23 error code meaning all files haven't been copied. The good news: I've identified the problem. My patch is trying to follow symlinks when it shouldn't. This is a minor issue, the rsync should work nice to backup disks without aliases. For the aliases, it will take resource fork from the original file. Annoying, but not a big problem. The bad one: The simple way to say it to no follow symlinks appeared on 10.4 API... I've already tried some things, but it will be a little bit complicated to fix it. Well, problem identified, v0.4 will be released as soon as possible to fix it. I would say before the weekend. Thanks for testing and submitting bug reports. Vitorio PS: About backup bouncer test: Verifying:basic-permissions ... ok Verifying: timestamps ... Sub-test:modification time ... ok ok Verifying: symlinks ... ok Verifying:symlink-ownership ... ok Verifying:hardlinks ... FAIL Verifying: resource-forks ... FAIL Verifying: finder-flags ... FAIL Verifying: finder-locks ... ok Verifying:creation-date ... ok Verifying:bsd-flags ... ok Verifying: extended-attrs ... Sub-test: on files ... ok Don't expect this to work as 10.3 does not handle extended attributes other than resource fork and finder info Sub-test: on directories ... FAIL Don't expect this to work as 10.3 does not handle extended attributes other than resource fork and finder info Sub-test: on symlinks ... FAIL Don't expect this to work as 10.3 does not handle extended attributes other than resource fork and finder info FAIL Verifying: access-control-lists ... Sub-test: on files ... ok Don't expect this to work as 10.3 does not handle ACLs Sub-test: on dirs ... ok Don't expect this to work as 10.3 does not handle ACLs ok Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... FAIL Don't expect this to work as 10.3 does not handle extended attributes other than resource fork and finder info Sub-test: lots of metadata ... FAIL Don't expect this to work as 10.3 does not handle extended attributes other than resource fork and finder info FAIL -- 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
Some answers for your questions: 1) rsync: ACLs are not supported on this client rsync error: syntax or usage error (code 1) at main.c(1454) [client=3.0.0pre9] no, you can't use -A (--acls) option with this version of rsync, as you compiled it without. And it's impossible to compile it with ACL support in 10.3. As 10.3 and 10.4 doesn't use ACL, this shouldn't be a major issue. You should only be aware to do not transfer files from a 10.5 computer by a 10.3 one (like 2 systems on the same machine, or shared folders over the network), as it would loose ACLs. 2) you have this in configure: checking whether to support ACLs... running tests: checking for acl_get_file in -lacl... no checking for ACL support... no checking ACL test results... No ACL support found I just have: checking whether to support ACLs... no but maybe because on this one I disabled ACL's in configure... Exactly. If you force --disable-acl-support it won't do some tests as you explicitly said to it to disable ACL. But the result is exactly the same. 3) then I ran the same test with your patched rsync in leopard using the same options (no A): Verifying:basic-permissions ... ok Verifying: timestamps ... Sub-test:modification time ... ok ok Verifying: symlinks ... FAIL Verifying:symlink-ownership ... FAIL Verifying:hardlinks ... ok Verifying: resource-forks ... ok Verifying: finder-flags ... FAIL Verifying: finder-locks ... ok Verifying:creation-date ... ok Verifying:bsd-flags ... ok Verifying: extended-attrs ... Sub-test: on files ... FAIL Sub-test: on directories ... FAIL Sub-test: on symlinks ... FAIL FAIL Verifying: access-control-lists ... Sub-test: on files ... FAIL Sub-test: on dirs ... FAIL FAIL Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... FAIL Sub-test: lots of metadata ... FAIL FAIL it looks like rsync is not using the original patches for flags etc but using yours instead perhaps? Is it supposed to override your patch if the system is greater than 10.3.9? Or maybe because it was compiled on 10.3.2? at any rate, huge progress. Thanks so much. I await any further developments. Rob ps the bouncer results without your patch and compiled on leopard: Verifying:basic-permissions ... ok Verifying: timestamps ... Sub-test:modification time ... ok ok Verifying: symlinks ... ok Verifying:symlink-ownership ... ok Verifying:hardlinks ... ok Verifying: resource-forks ... ok Verifying: finder-flags ... ok Verifying: finder-locks ... ok Verifying:creation-date ... ok Verifying:bsd-flags ... ok Verifying: extended-attrs ... Sub-test: on files ... ok Sub-test: on directories ... ok Sub-test: on symlinks ... ok ok Verifying: access-control-lists ... Sub-test: on files ... ok Sub-test: on dirs ... ok ok Verifying: fifo ... FAIL Verifying: devices ... FAIL Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... ok Sub-test: lots of metadata ... ok ok This behaviour is completely normal. The rsync functions are decided at the compilation time (maybe we should change some options to the execution time later, if it's possible?). So the patched rsync compiled on 10.3 won't use ACLs and probably other functions, even if you use the program on 10.4 or 10.5. All functionalities are decided at the compilation time by the configure script. In another hand, the patched rsync with 10.3 extended attributes support should compile as the unpatched one in 10.4 or 10.5 and present the same functionalities. This may be useless for people that don't use 10.3, but can be useful to have only one source code for all the systems and just recompile if needed. 4) I did notice that applescript files didn't show up in the finder but they were there if I ran ls command on the copy folder. Could you give me more details about those files? Do they have only resource fork or also data fork? A simple way to verify: ls -la /the/path/to/the/folder/having/the/problematic/file than ls -la /the/path/to/the/folder/having/the/problematic/file/rsrc Example on a text clipping (that is pure resource fork): iLaG:~/Desktop/rsync-3.0.0pre9 lag$ ls -la /Users/lag/Desktop/I\ dragged\ a\ text\ clipping\ in.textClipping -rw-r--r-- 1 lag lag 0 Jan 21 20:48 /Users/lag/Desktop/I dragged a text clipping in.textClipping iLaG:~/Desktop/rsync-3.0.0pre9 lag$ ls -la /Users/lag/Desktop/I\ dragged\ a\ text\ clipping\ in.textClipping/rsrc -rw-r--r-- 1 lag lag 3951 Jan 21 20:48 /Users/lag/Desktop/I dragged a text clipping
Re: Making rsync compile under Mac OS X 10.3.9 with extended attributes
v0.3 is here! And bug of invisible files is out! It was another silly bug... getattrlist puts in the buffer the length of the data then the data. setattrlist gets a buffer with only the data... So in the copy the data was padded of a long size, and the Finder flags were messed up, and sometimes the invisible flag was set... I've got the clue here http://irumors.wordpress.com/2007/01/31/how-to- make-finder-items-invisible-via-terminal/ and more particularly with the excelent /Developer/Tools/GetFileInfo who shown all flags padded from original and copy. If you want to test it on a Tiger or Leopard machine, it's possible. When configuring, use ./configure --host=powerpc-apple-darwin7.9.0 -- disable-acl-support to compile it as if you were using Panther. This patch should also work on Jaguar, Puma and even Cheetah. The carbon API I used is available since 10.0. So if the rest of rsync doesn't use features not available on those systems, it should compile fine. Well, this version is less buggy, but it still a test version, so as always, don't trust it results until checking it's all ok! Vitorio rsync10.3xattr_supportv0.3.diff Description: Binary data -- 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
Better news! It compiles and it works! I'm joining the .diff to apply on a 3.0.0pre9 with flags and crtimes patches. But as I said before, this is an alpha version, need testing before saying it's functional. Be careful using it, it potentially still may contains odd bugs! I've successfully cloned the sources folder with it ( ./rsync -aXNv --stats . ../rsync-copy ) but it crashes when I try a folder with a resourcefork file: Ordinateur-de-LaG:~/Desktop/rsync-test lag$ ./rsync -aXN --stats .. ~/rsynctest cmd=NULL machine=NULL user=NULL path=/Users/lag/rsynctest cmd[0]=. cmd[1]=/Users/lag/rsynctest note: iconv_open(US-ASCII, US-ASCII) succeeded. (Server) Protocol versions: remote=30, negotiated=30 (Client) Protocol versions: remote=30, negotiated=30 sending incremental file list [sender] make_file(.,*,2) [sender] expand rsync_xa to 100 bytes, did move [sender] expand item_list to 1200 bytes, did move [sender] expand rsync_xa to 20 bytes, did move [sender] make_file(.DS_Store,*,2) [sender] expand rsync_xa to 100 bytes, did move [sender] expand rsync_xa to 20 bytes, did move [sender] make_file(.localized,*,2) [sender] expand rsync_xa to 100 bytes, did move [sender] make_file(autoconf-2.61,*,2) [sender] expand rsync_xa to 100 bytes, did move [sender] make_file(autoconf-2.61.tar,*,2) [sender] expand rsync_xa to 100 bytes, did move [sender] make_file(configure.in,*,2) [sender] expand rsync_xa to 100 bytes, did move [sender] make_file(ons.o io.o compat.o hlink.o .textClipping,*,2) [sender] expand rsync_xa to 100 bytes, did move rsync: writefd_unbuffered failed to write 79 bytes [receiver]: Broken pipe (32) _exit_cleanup(code=12, file=io.c, line=1500): entered rsync error: error in rsync protocol data stream (code 12) at io.c(1500) [receiver=3.0.0pre9] _exit_cleanup(code=12, file=io.c, line=1500): about to call exit(12) Bus error Ordinateur-de-LaG:~/Desktop/rsync-test lag$ ls -la .. total 9816 drwx-- 15 lag lag 510 15 Feb 15:55 . drwxr-xr-x 16 lag lag 544 15 Feb 16:03 .. -rw---1 lag lag15364 15 Feb 16:04 .DS_Store -rw-r--r--1 lag lag0 13 Feb 10:17 .localized drwxr-xr-x 33 lag lag 1122 13 Feb 18:38 autoconf-2.61 -rw-r--r--1 lag lag 4904960 13 Feb 18:32 autoconf-2.61.tar -rw-r--r--1 lag lag29270 11 Feb 17:22 configure.in -rw-r--r--1 lag lag0 15 Feb 15:55 ons.o io.o compat.o hlink.o .textClipping -rw-r--r--1 lag lag11514 13 Feb 12:05 patch.diff drwxr-xr-x 96 lag lag 3264 13 Feb 21:31 rsync-3.0.0pre9 drwxr-xr-x 139 lag lag 4726 15 Feb 16:00 rsync-test -r--r--r--1 lag lag 4534 13 Feb 10:54 rsync10.3xattr_support.matt20080212.diff -rw-r--r--1 lag lag16941 13 Feb 21:43 rsync10.3xattr_support.vitorio20080213.diff -rw-r--r--1 lag lag 3652 15 Feb 15:39 rsync10.3xattr_support.vitorio20080215.diff -rw-r--r--1 lag lag18130 15 Feb 15:40 rsync10.3xattr_supportv0.1.diff It crashes without creating any single file on destination. I'm stopping by now, maybe I'll continue with some work on it tonight. But I'm already very happy that it compiles and works a little. It's in the right way :) As always, if someone knows where this bus error comes from, feel free to help... Vitorio rsync10.3xattr_supportv0.1.diff Description: Binary data -- 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 Fri, 2008-02-15 at 11:09 +0100, Vitorio Machado wrote: 1) We need to put the -framework Carbon on the linking part of the makefile. I'm trying to put it in the darwin4-7 part of the configure.in (lines 937 and above) like this: darwin[[4-7]].*) AC_MSG_RESULT(Using OS X PreTiger attrs) AC_DEFINE(HAVE_OSX_XATTRS, 1, [True if you have Mac OS X xattrs]) AC_DEFINE(HAVE_PRE_TIGER_OSX_ATTRS, 1, [True if you have Mac OS X PreTiger attrs]) AC_DEFINE(SUPPORT_XATTRS, 1) SYSXATTRS_CFLAGS=-framework Carbon LDFLAGS=$LDFLAGS -framework Carbon ;; Is it the right way? Yes, that should work fine. 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 Fri, 2008-02-15 at 16:10 +0100, Vitorio Machado wrote: Better news! It compiles and it works! I'm joining the .diff to apply on a 3.0.0pre9 with flags and crtimes patches. Congratulations on the progress! But as I said before, this is an alpha version, need testing before saying it's functional. Be careful using it, it potentially still may contains odd bugs! I've successfully cloned the sources folder with it ( ./rsync -aXNv --stats . ../rsync-copy ) but it crashes when I try a folder with a resourcefork file: Ordinateur-de-LaG:~/Desktop/rsync-test lag$ ./rsync -aXN --stats .. ~/rsynctest cmd=NULL machine=NULL user=NULL path=/Users/lag/rsynctest cmd[0]=. cmd[1]=/Users/lag/rsynctest note: iconv_open(US-ASCII, US-ASCII) succeeded. (Server) Protocol versions: remote=30, negotiated=30 (Client) Protocol versions: remote=30, negotiated=30 sending incremental file list [sender] make_file(.,*,2) [sender] expand rsync_xa to 100 bytes, did move [sender] expand item_list to 1200 bytes, did move [sender] expand rsync_xa to 20 bytes, did move [sender] make_file(.DS_Store,*,2) [sender] expand rsync_xa to 100 bytes, did move [sender] expand rsync_xa to 20 bytes, did move [sender] make_file(.localized,*,2) [sender] expand rsync_xa to 100 bytes, did move [sender] make_file(autoconf-2.61,*,2) [sender] expand rsync_xa to 100 bytes, did move [sender] make_file(autoconf-2.61.tar,*,2) [sender] expand rsync_xa to 100 bytes, did move [sender] make_file(configure.in,*,2) [sender] expand rsync_xa to 100 bytes, did move [sender] make_file(ons.o io.o compat.o hlink.o .textClipping,*,2) [sender] expand rsync_xa to 100 bytes, did move rsync: writefd_unbuffered failed to write 79 bytes [receiver]: Broken pipe (32) _exit_cleanup(code=12, file=io.c, line=1500): entered rsync error: error in rsync protocol data stream (code 12) at io.c(1500) [receiver=3.0.0pre9] _exit_cleanup(code=12, file=io.c, line=1500): about to call exit(12) Bus error Ordinateur-de-LaG:~/Desktop/rsync-test lag$ ls -la .. total 9816 drwx-- 15 lag lag 510 15 Feb 15:55 . drwxr-xr-x 16 lag lag 544 15 Feb 16:03 .. -rw---1 lag lag15364 15 Feb 16:04 .DS_Store -rw-r--r--1 lag lag0 13 Feb 10:17 .localized drwxr-xr-x 33 lag lag 1122 13 Feb 18:38 autoconf-2.61 -rw-r--r--1 lag lag 4904960 13 Feb 18:32 autoconf-2.61.tar -rw-r--r--1 lag lag29270 11 Feb 17:22 configure.in -rw-r--r--1 lag lag0 15 Feb 15:55 ons.o io.o compat.o hlink.o .textClipping -rw-r--r--1 lag lag11514 13 Feb 12:05 patch.diff drwxr-xr-x 96 lag lag 3264 13 Feb 21:31 rsync-3.0.0pre9 drwxr-xr-x 139 lag lag 4726 15 Feb 16:00 rsync-test -r--r--r--1 lag lag 4534 13 Feb 10:54 rsync10.3xattr_support.matt20080212.diff -rw-r--r--1 lag lag16941 13 Feb 21:43 rsync10.3xattr_support.vitorio20080213.diff -rw-r--r--1 lag lag 3652 15 Feb 15:39 rsync10.3xattr_support.vitorio20080215.diff -rw-r--r--1 lag lag18130 15 Feb 15:40 rsync10.3xattr_supportv0.1.diff It crashes without creating any single file on destination. As always, if someone knows where this bus error comes from, feel free to help... Which file has the resource fork? ons.o io.o compat.o hlink.o .textClipping? I think a bus error indicates an out-of-bounds memory access. First we need to establish which rsync process is incurring the bus error; since only the receiver manages to print out an error message, I think the sender is the one dying with the bus error. Run rsync under gdb and see if you can get a backtrace for where the bus error occurs. If you can't do that, then add some rprintf(FINFO, ...) calls to the code to see how far rsync is getting before it crashes. 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
I've corrected the bug that was making rsync crash, a silly pointer issue (was using value instead of value, shame on me). I've also corrected a bracket bug in sys_llistxattr: sizeof foo is dangerous as sizeof is a macro, works fine as value, but on return variable it bugs. I've changed in sizeof(foo). Also putted some printfs to be able to debug easily when verbose 3 (option -). Now it's working here, there is only a Finder bug that doesn't display a file with only a resource fork. Ordinateur-de-LaG:~/Desktop/rsync-test lag$ ls -la ../test/ total 24 drwxr-xr-x 4 lag lag 136 15 Feb 21:53 . drwx-- 11 lag lag 374 15 Feb 22:17 .. -rw-r--r-- 1 lag lag 6148 15 Feb 21:53 .DS_Store -rw-r--r-- 1 lag lag 0 15 Feb 15:55 ons.o io.o compat.o hlink.o .textClipping Ordinateur-de-LaG:~/Desktop/rsync-test lag$ ls -la ../test/ons.o\ io.o\ compat.o\ hlink.o\ .textClipping/rsrc -rw-r--r-- 1 lag lag 2617 15 Feb 15:55 ../test/ons.o io.o compat.o hlink.o .textClipping/rsrc Ordinateur-de-LaG:~/Desktop/rsync-test lag$ ls -la ~/rsynctest/ total 8 drwxr-xr-x 3 lag lag 102 15 Feb 22:06 . drwxr-xr-x 17 lag lag 578 15 Feb 22:03 .. -rw-r--r-- 1 lag lag0 15 Feb 15:55 ons.o io.o compat.o hlink.o .textClipping Ordinrdinateur-de-LaG:~/Desktop/rsync-test lag$ ls -la ~/rsynctest/ons.o\ io.o\ compat.o\ hnnkk.textClipping/rsrc -rw-r--r-- 1 lag lag 2617 15 Feb 15:55 /Users/lag/rsynctest/ons.o io.o compat.o hlink.o .textClipping/rsrc Ordinateur-de-LaG:~/Desktop/rsync-test lag$ cat ~/rsynctest/ons.o\ io.o\ compat.o\ hlink.o\ .textClipping/rsrc ?Z?ons.o io.o compat.o hlink.o token.o uidlist.o socket.o hashtable.o fileio.o batch.o clientname.o chmod.o acls.o xattrs.o progress.o pipe.o params.o loadparm.o clientserver.o access.o connection.o authenticate.o lib/wildmatch.o lib/compat.o lib/snprintf.o lib/mdfour.o lib/md5.o lib/permstring.o lib/pool_alloc.o lib/sysacls.o lib/sysxattrs.o zlib/deflate.o zlib/inffast.o zlib/inflate.o zlib/inftrees.o zlib/trees.o zlib/zutil.o zlib/adler32.o zlib/compress.o zlib/crc32.o popt/findme.o popt/popt.o popt/poptconfig.o popt/popthelp.o popt/poptparse.o rsync tls getgroups getfsdev trimslash t_unsafe wildtest tls.o getgroups.o getfsdev.o t_stub.o t_unsafe.o trimslash.o wildtest.o testsuite/chown-fake.test testsuite/devices-fake.test \?ons.o io.o compat.o hlink.o token.o uidlist.o socket.o hashtable.o fileio.o batch.o clientname.o chmod.o acls.o xattrs.o progress.o pipe.o params.o loadparm.o clientserver.o access.o connection.o authenticate.o lib/wildmatch.o lib/compat.o lib/snprintf.o lib/mdfour.o lib/md5.o lib/permstring.o lib/pool_alloc.o lib/sysacls.o lib/sysxattrs.o zlib/deflate.o zlib/inffast.o zlib/inflate.o zlib/inftrees.o zlib/trees.o zlib/zutil.o zlib/adler32.o zlib/compress.o zlib/crc32.o popt/findme.o popt/popt.o popt/poptconfig.o popt/popthelp.o popt/poptparse.o rsync tls getgroups getfsdev trimslash t_unsafe wildtest tls.o getgroups.o getfsdev.o t_stub.o t_unsafe.o trimslash.o wildtest.o testsuite/chown-fake.test testsuite/devices-fake.test \0utxtTEXT ?Z ?QZutxtTEXTdrag2??___?Ordinateur-de-LaG:~/Desktop/rsync-test lag$ As you can see, on the Terminal the Text Clipping ons.o io.o compat.o hlink.o .textClipping is just fine, but it won't appear in the Finder even after deleting the .DS_Store. Maybe rsync see an empty data fork and doesn't create a data fork in the destination file. But maybe it's only the Panther's Finder that is buggy. @Rob: Are you sure you proceed as this for patching? 1) Download a fresh 3.0.0pre9 rsync and its patches folder 2) Put the patches folder into the rsync folder 3) Launch a Terminal and go to rsync folder (example: cd ~/Desktop/rsync) 4) Copy past the command: patch -p1 patches/flags.diff 5) Copy past the command: patch -p1 patches/crtimes.diff 6) Use the command: patch -p1 path/to/rsync10.3xattr_supportv0.2.diff substituting path/to by the right path 7) ./configure 8) make The error you described me comes from ACL that seems to be built in your config but it should be off as 10.3 doesn't support ACLs. Your ./configure should end like this: checking whether -c -o works... yes checking sys/acl.h usability... no checking sys/acl.h presence... no checking for sys/acl.h... no checking acl/libacl.h usability... no checking acl/libacl.h presence... no checking for acl/libacl.h... no checking for _acl... no checking for __acl... no checking for _facl... no checking for __facl... no checking whether to support ACLs... running tests: checking for acl_get_file in -lacl... no checking for ACL support... no checking ACL test results... No ACL support found checking attr/xattr.h usability... no checking attr/xattr.h presence... no checking for attr/xattr.h... no checking sys/xattr.h usability... no checking sys/xattr.h presence... no checking for sys/xattr.h... no checking sys/extattr.h usability... no checking sys/extattr.h
Re: Making rsync compile under Mac OS X 10.3.9 with extended attributes
On Wed, 2008-02-13 at 22:13 +0100, LaG' wrote: 1) Patched ACL configure.in (don't know if I did it the right way) to don't say it can use ACL on a Panther system. Changed ! darwin*) to ! darwin[[0-38-9]].*) Presumably versions 10 and greater of darwin will support ACLs, but that pattern doesn't match them. Also, I don't think there's a need to match versions 0 through 3. Try this: darwin[[89]].*|darwin[[1-9]][[0-9]]*) The first pattern matches versions 8 and 9, and the second matches any version with two or more digits before the first dot. 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
Hmmm, yes, I need to remove the dot: darwin[[0-38-9]]*) should do it, no? Otherwise, I'm looking about how to compile Carbon code. It seems that it will be portable to 10.1 or 10.2 because instead of: -I /Developer/SDKs/MacOSX10.3.0.sdk/Developer/Headers/CFMCarbon/ It seems that we only need to put -framework Carbon With this I resolved the header conflict problem, but it doesn't recognise types that should be defined by Carbon framework, like FSIORefNum. I'm still investigating what are the correct parameters to put in gcc. How I didn't find much documentation about it, I'm trying to reverse engineering XCode. Opening Carbon example projects and trying to find gcc options in the compiler log to see what's used. Maybe with some luck tomorrow I find a clue... As always, I'm not working alone, if someone who reads this have some knowledge to share, just do it :) Have a nice evening, Vitorio Le 14 févr. 08 à 20:02, Matt McCutchen a écrit : On Wed, 2008-02-13 at 22:13 +0100, LaG' wrote: 1) Patched ACL configure.in (don't know if I did it the right way) to don't say it can use ACL on a Panther system. Changed ! darwin*) to ! darwin[[0-38-9]].*) Presumably versions 10 and greater of darwin will support ACLs, but that pattern doesn't match them. Also, I don't think there's a need to match versions 0 through 3. Try this: darwin[[89]].*|darwin[[1-9]][[0-9]]*) The first pattern matches versions 8 and 9, and the second matches any version with two or more digits before the first dot. 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-02-14 at 23:38 +0100, Vitorio Machado wrote: Hmmm, yes, I need to remove the dot: darwin[[0-38-9]]*) should do it, no? That won't match darwin version 40. :) 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
OK, you won :P But how I said in the first time, isn't there a proper way to patch ACL detection? I mean that for OS X 10.3, configure wil say no, no, no for all ACLs precheck (the acl headers and functions) but it will branch on the cases. As I've seen on xattr it works differently. There is a maybe set if it find something that could work and only then it goes to system detection. I think the best way to patch the ACL detection in the configure script would be doing this maybe too. The problem is that xattr is based on functions to say it could work, and ACL is based on header detection, so it doesn't seem quite the same thing. How I'm not skilled enough and this isn't my main focus today, I preferred leave it like this and patch in a fast way. But I don't think the program will remain stable a long time if we patch all problems in a fast way like this. You know better than me what's the right thing to do, if you think there is no problem on only doing the darwin version check, it will be OK for me too. I only have the impression that there is a better way to proceed. Vitorio Le 15 févr. 08 à 01:07, Matt McCutchen a écrit : On Thu, 2008-02-14 at 23:38 +0100, Vitorio Machado wrote: Hmmm, yes, I need to remove the dot: darwin[[0-38-9]]*) should do it, no? That won't match darwin version 40. :) 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
Hello, Today I worked on a real 10.3 mac. I'm attaching a patch based on rsync 3.0.0pre9 with flags and crtimes patches. I hope I did it right, I used this command: diff -rPC2 ../rsync-3.0.0pre9/ .../patch2.diff So, from 3.0.0pre9 this patch includes the work on my server ( http://shared.and.free.fr ), Matt modifications from yesterday and from today: 1) Patched ACL configure.in (don't know if I did it the right way) to don't say it can use ACL on a Panther system. Changed ! darwin*) to ! darwin[[0-38-9]].*) So on PreTiger systems it doesn't set ACL by default. The system doesn't handle it anyway. From ./configure: before: checking sys/acl.h usability... no checking sys/acl.h presence... no checking for sys/acl.h... no checking acl/libacl.h usability... no checking acl/libacl.h presence... no checking for acl/libacl.h... no checking for _acl... no checking for __acl... no checking for _facl... no checking for __facl... no checking whether to support ACLs... Using OS X ACLs after patching: checking sys/acl.h usability... no checking sys/acl.h presence... no checking for sys/acl.h... no checking acl/libacl.h usability... no checking acl/libacl.h presence... no checking for acl/libacl.h... no checking for _acl... no checking for __acl... no checking for _facl... no checking for __facl... no checking whether to support ACLs... running tests: checking for acl_get_file in -lacl... no checking for ACL support... no checking ACL test results... No ACL support found I think maybe the patch should be corrected to don't even go into the cases if it doesn't find the headers it expects, but this goes beyond my knowledge. 2) Matt: I put * instead of 3.9 to try to make the option work on pre-Tiger systems other than 10.3.9. Unfortunately this doesn't works: gcc -std=gnu99 -I. -I. -I /Developer/SDKs/MacOSX10.*.sdk/Developer/Headers/CFMCarbon/ -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c lib/sysxattrs.c -o lib/sysxattrs.o gcc: cannot specify -o with -c or -S and multiple compilations make: *** [lib/sysxattrs.o] Error 1 So I reverted the path, but this will also have to change because the inclusion isn't good (see next point). 3) We still have a conflict between Carbon inclusion and other headers. I'm starting to google around, and already found some people that has the same problem. With some luck they already found a solution. The conflicts look like this: gcc -std=gnu99 -I. -I. -I /Developer/SDKs/MacOSX10.3.0.sdk/Developer/Headers/CFMCarbon/ -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c lib/sysxattrs.c -o lib/sysxattrs.o In file included from rsync.h:236, from lib/sysxattrs.c:21: /usr/include/stdio.h:81: error: parse error before fpos_t /usr/include/stdio.h:143: error: parse error before fpos_t /usr/include/stdio.h:160: error: parse error before _offset /usr/include/stdio.h:164: error: parse error before __sF GCC finds errors on existing headers. Seems like same types are defined twice or something like this. I'll now look here for something: http://www.google.com/search?client=safarirls=fr- frq=framework+Carbon+header+conflictie=UTF-8oe=UTF-8 If you find a more relevant site/keywords, please share it :) PS: Thanks for the strncpy correction. Vitorio Le 13 févr. 08, à 03:26, Matt McCutchen a écrit : On Tue, 2008-02-12 at 15:24 +0100, Vitorio Machado wrote: I'm trying to figure out how to modify the makefile to say to compile sysxattrs.c with the -I /Developer/SDKs/MacOSX10.3.9.sdk/Developer/ Headers/CFMCarbon/ in the case of HAVE_PRE_TIGER_OSX_ATTRS is true. Is somebody skilled on makefile to give me some help? I did some work on top of your rsync10.3xattr_support080211 files. I added code to configure.in and Makefile.in that should get the appropriate -I option passed for lib/sysxattrs.c in the case of HAVE_PRE_TIGER_OSX_ATTRS. You can modify the option in configure.in if necessary. I put * instead of 3.9 to try to make the option work on pre-Tiger systems other than 10.3.9. I also think I figured out why the configure script was refusing to enable HAVE_PRE_TIGER_OSX_ATTRS. First, every time you change configure.in, you need to run autoconf -o configure.sh to update configure.sh (the underlying configure script for which ./configure is a simple wrapper). The ./configure wrapper will invoke autoconf to generate configure.sh if it doesn't exist, but once it exists, you have to regenerate it yourself as necessary. Second, the [] characters in darwin[4-7]* in configure.in are recognized by autoconf as quoting characters and stripped out, so configure.sh says darwin4-7* , which obviously won't match. I changed configure.in to say darwin[[4-7]]* ; autoconf strips only the outer pair to leave the desired darwin[4-7]* in configure.sh. I also neatened up the code in other places and finished your strncpy call. A patch with my proposed changes on top of your files is attached. Matt
Re: Making rsync compile under Mac OS X 10.3.9 with extended attributes
Normally all the infos to correctly setup gcc with carbon should be here: http://developer.apple.com/documentation/MacOSX/Conceptual/ BPFrameworks/Tasks/IncludingFrameworks.html I'll carefully read it tomorrow... By now I need some sleep ;) Good night folks! Le 13 févr. 08, à 22:13, LaG' a écrit : Hello, Today I worked on a real 10.3 mac. I'm attaching a patch based on rsync 3.0.0pre9 with flags and crtimes patches. I hope I did it right, I used this command: diff -rPC2 ../rsync-3.0.0pre9/ .../patch2.diff So, from 3.0.0pre9 this patch includes the work on my server ( http://shared.and.free.fr ), Matt modifications from yesterday and from today: 1) Patched ACL configure.in (don't know if I did it the right way) to don't say it can use ACL on a Panther system. Changed ! darwin*) to ! darwin[[0-38-9]].*) So on PreTiger systems it doesn't set ACL by default. The system doesn't handle it anyway. From ./configure: before: checking sys/acl.h usability... no checking sys/acl.h presence... no checking for sys/acl.h... no checking acl/libacl.h usability... no checking acl/libacl.h presence... no checking for acl/libacl.h... no checking for _acl... no checking for __acl... no checking for _facl... no checking for __facl... no checking whether to support ACLs... Using OS X ACLs after patching: checking sys/acl.h usability... no checking sys/acl.h presence... no checking for sys/acl.h... no checking acl/libacl.h usability... no checking acl/libacl.h presence... no checking for acl/libacl.h... no checking for _acl... no checking for __acl... no checking for _facl... no checking for __facl... no checking whether to support ACLs... running tests: checking for acl_get_file in -lacl... no checking for ACL support... no checking ACL test results... No ACL support found I think maybe the patch should be corrected to don't even go into the cases if it doesn't find the headers it expects, but this goes beyond my knowledge. 2) Matt: I put * instead of 3.9 to try to make the option work on pre-Tiger systems other than 10.3.9. Unfortunately this doesn't works: gcc -std=gnu99 -I. -I. -I /Developer/SDKs/MacOSX10.*.sdk/Developer/Headers/CFMCarbon/ -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c lib/sysxattrs.c -o lib/sysxattrs.o gcc: cannot specify -o with -c or -S and multiple compilations make: *** [lib/sysxattrs.o] Error 1 So I reverted the path, but this will also have to change because the inclusion isn't good (see next point). 3) We still have a conflict between Carbon inclusion and other headers. I'm starting to google around, and already found some people that has the same problem. With some luck they already found a solution. The conflicts look like this: gcc -std=gnu99 -I. -I. -I /Developer/SDKs/MacOSX10.3.0.sdk/Developer/Headers/CFMCarbon/ -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c lib/sysxattrs.c -o lib/sysxattrs.o In file included from rsync.h:236, from lib/sysxattrs.c:21: /usr/include/stdio.h:81: error: parse error before fpos_t /usr/include/stdio.h:143: error: parse error before fpos_t /usr/include/stdio.h:160: error: parse error before _offset /usr/include/stdio.h:164: error: parse error before __sF GCC finds errors on existing headers. Seems like same types are defined twice or something like this. I'll now look here for something: http://www.google.com/search?client=safarirls=fr- frq=framework+Carbon+header+conflictie=UTF-8oe=UTF-8 If you find a more relevant site/keywords, please share it :) PS: Thanks for the strncpy correction. Vitorio Le 13 févr. 08, à 03:26, Matt McCutchen a écrit : On Tue, 2008-02-12 at 15:24 +0100, Vitorio Machado wrote: I'm trying to figure out how to modify the makefile to say to compile sysxattrs.c with the -I /Developer/SDKs/MacOSX10.3.9.sdk/Developer/ Headers/CFMCarbon/ in the case of HAVE_PRE_TIGER_OSX_ATTRS is true. Is somebody skilled on makefile to give me some help? I did some work on top of your rsync10.3xattr_support080211 files. I added code to configure.in and Makefile.in that should get the appropriate -I option passed for lib/sysxattrs.c in the case of HAVE_PRE_TIGER_OSX_ATTRS. You can modify the option in configure.in if necessary. I put * instead of 3.9 to try to make the option work on pre-Tiger systems other than 10.3.9. I also think I figured out why the configure script was refusing to enable HAVE_PRE_TIGER_OSX_ATTRS. First, every time you change configure.in, you need to run autoconf -o configure.sh to update configure.sh (the underlying configure script for which ./configure is a simple wrapper). The ./configure wrapper will invoke autoconf to generate configure.sh if it doesn't exist, but once it exists, you have to regenerate it yourself as necessary. Second, the [] characters in darwin[4-7]* in configure.in are recognized by autoconf as quoting characters and stripped out, so configure.sh says darwin4-7* , which obviously won't match. I changed
Re: Making rsync compile under Mac OS X 10.3.9 with extended attributes
On Tue, 2008-02-12 at 15:24 +0100, Vitorio Machado wrote:
I'm trying to figure out how to modify the makefile to say to compile
sysxattrs.c with the -I /Developer/SDKs/MacOSX10.3.9.sdk/Developer/
Headers/CFMCarbon/
in the case of HAVE_PRE_TIGER_OSX_ATTRS is true.
Is somebody skilled on makefile to give me some help?
I did some work on top of your rsync10.3xattr_support080211 files. I
added code to configure.in and Makefile.in that should get the
appropriate -I option passed for lib/sysxattrs.c in the case of
HAVE_PRE_TIGER_OSX_ATTRS. You can modify the option in configure.in if
necessary. I put * instead of 3.9 to try to make the option work on
pre-Tiger systems other than 10.3.9.
I also think I figured out why the configure script was refusing to
enable HAVE_PRE_TIGER_OSX_ATTRS. First, every time you change
configure.in, you need to run autoconf -o configure.sh to update
configure.sh (the underlying configure script for which ./configure is a
simple wrapper). The ./configure wrapper will invoke autoconf to
generate configure.sh if it doesn't exist, but once it exists, you have
to regenerate it yourself as necessary. Second, the [] characters in
darwin[4-7]* in configure.in are recognized by autoconf as quoting
characters and stripped out, so configure.sh says darwin4-7* , which
obviously won't match. I changed configure.in to say darwin[[4-7]]* ;
autoconf strips only the outer pair to leave the desired darwin[4-7]*
in configure.sh.
I also neatened up the code in other places and finished your strncpy
call. A patch with my proposed changes on top of your files is
attached.
Matt
diff --git a/Makefile.in b/Makefile.in
index 4716aba..0145f59 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -61,6 +61,12 @@ CHECK_OBJS=tls.o getgroups.o getfsdev.o t_stub.o t_unsafe.o trimslash.o wildtest
all: conf_stop make_stop rsync$(EXEEXT) @MAKE_MAN@
+# Separate rule to accommodate extra options for lib/sysxattrs.o on pre-Tiger OS X
+lib/sysxattrs.o: lib/sysxattrs.c
[EMAIL PROTECTED]@
+ $(CC) -I. -I$(srcdir) @SYSXATTRS_CFLAGS@ $(CFLAGS) $(CPPFLAGS) -c $ @CC_SHOBJ_FLAG@
[EMAIL PROTECTED]@
+
install: all
-mkdir -p ${DESTDIR}${bindir}
${INSTALLCMD} ${INSTALL_STRIP} -m 755 rsync$(EXEEXT) ${DESTDIR}${bindir}
diff --git a/configure.in b/configure.in
index c6bc065..f629815 100644
--- a/configure.in
+++ b/configure.in
@@ -932,10 +932,14 @@ else
AC_DEFINE(HAVE_LINUX_XATTRS, 1, [True if you have Linux xattrs])
AC_DEFINE(SUPPORT_XATTRS, 1)
;;
- darwin[4567]*)
+# The square brackets in the next line are doubled in configure.in
+# because autoconf strips out one pair as quoting symbols.
+darwin[[4-7]].*)
AC_MSG_RESULT(Using OS X PreTiger attrs)
+ AC_DEFINE(HAVE_OSX_XATTRS, 1, [True if you have Mac OS X xattrs])
AC_DEFINE(HAVE_PRE_TIGER_OSX_ATTRS, 1, [True if you have Mac OS X PreTiger attrs])
AC_DEFINE(SUPPORT_XATTRS, 1)
+ SYSXATTRS_CFLAGS=-I /Developer/SDKs/MacOSX10.*.sdk/Developer/Headers/CFMCarbon/
;;
darwin*)
AC_MSG_RESULT(Using OS X xattrs)
@@ -956,6 +960,7 @@ else
;;
esac
fi
+AC_SUBST(SYSXATTRS_CFLAGS)
AC_CONFIG_FILES([Makefile lib/dummy zlib/dummy popt/dummy shconfig])
AC_OUTPUT
diff --git a/lib/sysxattrs.c b/lib/sysxattrs.c
index fae677f..bf267c7 100644
--- a/lib/sysxattrs.c
+++ b/lib/sysxattrs.c
@@ -54,6 +54,14 @@ ssize_t sys_llistxattr(const char *path, char *list, size_t size)
#ifdef HAVE_PRE_TIGER_OSX_ATTRS
+#include sys/attr.h
+#include unistd.h
+#include string.h
+#include CarbonCore/Files.h
+
+#define FINDER_INFO_XATTR_NAME com.apple.FinderInfo
+#define RESOURCE_FORK_XATTR_NAME com.apple.ResourceFork
+
ssize_t sys_lgetxattr(const char *path, const char *name, void *value, size_t size)
{
struct attrlist attrList; //List of attributes
@@ -68,7 +76,7 @@ ssize_t sys_lgetxattr(const char *path, const char *name, void *value, size_t si
attrList.forkattr=0;
/* Uses getattrlist to get FinderInfo */
- if(strcmp(name, com.apple.FinderInfo)==0)
+ if(strcmp(name, FINDER_INFO_XATTR_NAME)==0)
{
attrList.commonattr+=ATTR_CMN_FNDRINFO;
if(getattrlist(path, attrList, value, size, FSOPT_NOFOLLOW)==0)
@@ -77,7 +85,7 @@ ssize_t sys_lgetxattr(const char *path, const char *name, void *value, size_t si
return -1; /* Errno is setup by getattrlist */
}
/* Uses carbon to get ResourceFork */
- else if(strcmp(name, com.apple.ResourceFork)==0)
+ else if(strcmp(name, RESOURCE_FORK_XATTR_NAME)==0)
{
char path_with_name[PATH_MAX]; /* POSIX name of the file */
FSRef ref; /* A Carbon reference to the file (analogue to a POSIX Path) */
@@ -180,14 +188,14 @@ int sys_lsetxattr(const char *path, const char *name, const void *value, size_t
attrList.forkattr=0;
/* Uses getattrlist to get FinderInfo */
- if(strcmp(name, com.apple.FinderInfo)==0)
+ if(strcmp(name, FINDER_INFO_XATTR_NAME)==0)
{
attrList.commonattr+=ATTR_CMN_FNDRINFO;
return setattrlist(path, attrList, value, size, FSOPT_NOFOLLOW);
}
/* Uses carbon to set
Re: Making rsync compile under Mac OS X 10.3.9 with extended attributes
I'm trying to figure out how to modify the makefile to say to compile sysxattrs.c with the -I /Developer/SDKs/MacOSX10.3.9.sdk/Developer/ Headers/CFMCarbon/ in the case of HAVE_PRE_TIGER_OSX_ATTRS is true. Is somebody skilled on makefile to give me some help? Le 12 févr. 08 à 12:29, Vitorio Machado a écrit : It seems that this problem is generated by the inclusion of the Carbon API that have conflicting headers with the *NIX ones... I don't know if doing export C_INCLUDE_PATH=/Developer/SDKs/ MacOSX10.4.0.sdk/Developer/Headers/CFMCarbon/ is the correct way to link with the CarbonCore. -- 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
It seems that this problem is generated by the inclusion of the Carbon API that have conflicting headers with the *NIX ones... I don't know if doing export C_INCLUDE_PATH=/Developer/SDKs/ MacOSX10.4.0.sdk/Developer/Headers/CFMCarbon/ is the correct way to link with the CarbonCore. I'm trying some things unsuccessfully mainly because I'm really lost with all this complexity of configure, automake, linking etc. If somebody more skilled on compiling can help me on this, would be great! Thanks, Vitorio - a little lost in all those automatically generated code lines Le 11 févr. 08 à 23:35, Vitorio Machado a écrit : iMac:/Volumes/Nomade/Input/rsync-3.0.1 lag$ make perl ./mkproto.pl ./*.c ./lib/compat.c gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c flist.c -o flist.o In file included from rsync.h:351, from flist.c:23: /usr/include/sys/file.h:81: error: parse error before 'caddr_t' In file included from rsync.h:916, from flist.c:23: proto.h:301: error: parse error before 'u_long' flist.c: In function 'send_file_entry': flist.c:429: warning: implicit declaration of function 'major' flist.c:433: warning: implicit declaration of function 'minor' flist.c:437: warning: implicit declaration of function 'makedev' make: *** [flist.o] Error 1 -- 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
Hi people, What I have done today: 1) Downloaded a fresh copy of rsync 3.0.0pre9 2) patched with: patch -p1 patches/flags.diff patch -p1 patches/crtimes.diff 3) Overwrote sysxattrs.c, sysxattrs.h and configure.in with the ones from http://shared.and.free.fr/rsync10.3xattr_support080211/ What changed in those files: sysxattrs.h : #ifdef SUPPORT_XATTRS #if defined HAVE_ATTR_XATTR_H #include attr/xattr.h #elif defined HAVE_SYS_XATTR_H #include sys/xattr.h #elif defined HAVE_SYS_EXTATTR_H #include sys/extattr.h #elif defined HAVE_PRE_TIGER_OSX_ATTRS #include sys/attr.h #include unistd.h #include string.h #include Files.h #endif configure.in: line 555: extattr_get_link sigaction sigprocmask setattrlist getattrlist) line 920: [], [case $ac_cv_func_getxattr$ac_cv_func_extattr_get_link $ac_cv_func_getattrlist in line 935: darwin[4-7]*) AC_MSG_RESULT(Using OS X PreTiger attrs) AC_DEFINE(HAVE_PRE_TIGER_OSX_ATTRS, 1, [True if you have Mac OS X PreTiger attrs]) AC_DEFINE(SUPPORT_XATTRS, 1) ;; darwin[1-38-9]*) AC_MSG_RESULT(Using OS X xattrs) AC_DEFINE(HAVE_OSX_XATTRS, 1, [True if you have Mac OS X xattrs]) AC_DEFINE(SUPPORT_XATTRS, 1) ;; 4) ran ./configure --host=powerpc-apple-darwin7.9.0 (to simulate pre tiger machine) 5) ran make, who asked me to run make reconfigure because the configure script changed 6) ran make reconfigure 7) ran make But the --host in ./configure is not enough to force my 10.4 to act like a 10.3 system. Also tried --target and --build without success, it always shows me checking whether to support extended attributes... Using OS X xattrs instead of: checking whether to support extended attributes... Using OS X PreTiger xattrs So I've tried bruteforce mode, changed line 935 of configure.in to this: darwin[4-7]*) AC_MSG_RESULT(Using OS X PreTiger attrs) AC_DEFINE(HAVE_PRE_TIGER_OSX_ATTRS, 1, [True if you have Mac OS X PreTiger attrs]) AC_DEFINE(SUPPORT_XATTRS, 1) ;; darwin[1-38-9]*) # AC_MSG_RESULT(Using OS X xattrs) # AC_DEFINE(HAVE_OSX_XATTRS, 1, [True if you have Mac OS X xattrs]) AC_MSG_RESULT(Using OS X PreTiger attrs) AC_DEFINE(HAVE_PRE_TIGER_OSX_ATTRS, 1, [True if you have Mac OS X PreTiger attrs]) AC_DEFINE(SUPPORT_XATTRS, 1) So theoretically, even on Tiger it should enable HAVE_PRE_TIGER_OSX_ATTRS and I should test my code. But no! The damn Using OS X xattrs is always there on running ./configure or make reconfigure. I've searched, normally this sentence only appears in this part of the code. Even a make clean, closing and reopening the Terminal, nothing makes it accept my changes and show Using OS X PreTiger attr that would confirm I'll compile my branch of the code... Is something missing? A little bit of code to change somewhere else? Please, can somebody help me with this part of the process? I'm not used to GNU configure scripts... We are getting close! How frustrating to spend more time trying to configure the compilation script than coding... Best regards, Vitorio Le 27 janv. 08 à 13:54, Matt McCutchen a écrit : On Sun, 2008-01-27 at 13:10 +0100, Vitorio Machado wrote: For the way of recognizing the OS (pseudo-coded as mac 10.4), ./ configure gives target as powerpc-apple-darwin7.9.0 for 10.3.9, powerpc-apple-darwin8.11.0 for 10.4.11. darwinA.B.C represents Mac OS X 10.(A-4).B, so I think here is our way to create a flag like mac_bellow_tiger. But I don't know how to put this flag in the configure script, especially because it seems to be automatically generated, so would be better to patch the source than the result. Do someone knows how to do that? The configure script is generated from configure.in. It looks like all you have to do is add an extra test inside the darwin* case on line 892 to check if $host_os matches darwin[4567].* and, if so, define an additional macro HAVE_PRE_TIGER_OSX_ATTRS. Then lib/sysxattrs.* can test #ifdef HAVE_PRE_TIGER_OSX_ATTRS. You also need to make sure that the configure script enables xattr support by default (really the 10.3-specific pseudo-xattr support) even though 10.3 fails all of the tests for the real xattr headers. Probably the way to do this is to add getattrlist to the list of functions on line 555 whose presence is tested and add it on line 920 as one of the functions whose presence indicates that xattrs are worth a try. 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
Well, I don't know how, but cleaning the source folder, making ./ configure then make then make reconfigure it finally accepted my modified configure.in I could compile my modified sysxattr module with some problems: 1) Had to manually add: export C_INCLUDE_PATH=/Developer/SDKs/MacOSX10.4.0.sdk/Developer/ Headers/CFMCarbon/ To make it recognise the Carbon Framework 2) Had header trouble with: /* these are needed for the uid/gid mapping code */ #include pwd.h #include grp.h #include stdarg.h #include netinet/in.h #include arpa/inet.h #ifdef HAVE_NETDB_H #include netdb.h #endif #include syslog.h #include sys/file.h in rsync.h For an unknown reason, gcc makes parse error in sys/file.h. I could compile inverting the order like this: /* these are needed for the uid/gid mapping code */ #include sys/file.h #include pwd.h #include grp.h #include stdarg.h #include netinet/in.h #include arpa/inet.h #ifdef HAVE_NETDB_H #include netdb.h #endif #include syslog.h But now it doesn't want to compile flist.c for the same reason, and here the order doesn't matter :/ GCC log: iMac:/Volumes/Nomade/Input/rsync-3.0.1 lag$ make perl ./mkproto.pl ./*.c ./lib/compat.c gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c flist.c -o flist.o In file included from rsync.h:351, from flist.c:23: /usr/include/sys/file.h:81: error: parse error before 'caddr_t' In file included from rsync.h:916, from flist.c:23: proto.h:301: error: parse error before 'u_long' flist.c: In function 'send_file_entry': flist.c:429: warning: implicit declaration of function 'major' flist.c:433: warning: implicit declaration of function 'minor' flist.c:437: warning: implicit declaration of function 'makedev' make: *** [flist.o] Error 1 There should be 2 conflicting headers, but it's too late for me to search it now. PS: I've updated the files with the compiler corrections at the same address as before http://shared.and.free.fr/ rsync10.3xattr_support080211/ Good night! -- 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
Here is the last version of my integration of Resource Forks and Finder Info capabilities to OS X prior to Tiger: http:// shared.and.free.fr/sysxattrs_draft080210.c Changelog: - Coded the setter function - Made changes to getter to emulate the expected behaviour when sending NULL buffer and 0 size, to return the size of the arguments What I've noticed: there is no clean way to code sys_fgetxattr as it works with a file descriptor and the getattrlist only works with a path. There is no fonction like fgetattrlist and the easiest way to get a file path from it's file descriptor is to scan the filesystem looking for an inode number... What a performance issue! The good news: As I've seen in the code, sys_fgetxattr is only used by get_stat_xattr when called by x_fstat all from xattrs.c. But no code seems to call x_fstat, so it seems that this function is useless, at least by now. Someone can confirm this? TODO: - Put the good includes in the header file (easy) - Make a configure test to identify pre-tiger Macs (can somebody help me with this, I don't really know how to do it) - Test and debug it :) - Integrate this modification to the main code Good night, folks! Vitorio Le 7 févr. 08 à 23:33, Wayne Davison a écrit : On Thu, Feb 07, 2008 at 10:51:34PM +0100, Vitorio Machado wrote: I also noticed that sys_lgetxattr can not be called twice if the buffer size is too small, because there is no offset management. Is this normal? The code calls sys_lgetxattr() once with a NULL pointer and a 0 length to ask for the size. Then, it calls it with a buffer large enough to hold the attribute. So, the best solution would be to make your code just ask the OS how big an item is when there is no buffer pointer. If that is not possible, it should be easy to cache an object in a static in your function and re-use it for a following call where the name matches. ..wayne.. -- 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
Hello people! I'm back :) Yes, I had a little time today to put some lines of code into the draft of sysxattrs compatible with 10.3 and resource forks. With some optimism I could say it's almost done. Here is the code as it looks today: http://shared.and.free.fr/ sysxattrs_draft080207.c I've followed the Matt recommendations and putted the PRE_TIGER as a subcondition of OS_X, reordered the code to care only about resource fork and finder info. I've looked at the code of Mike Bombich in crtimes. I didn't understand all of it (principally because I've only quick looked at it), but it seems that it cares about crtimes completely independently of sysxattrs.c getxattr calls. So, I'm assuming his patch for crtimes will also work on PRE_TIGER. Am I right? Well, I've coded the reading of the resource forks in carbon. Still need: 1) The writing of resource fork (shouldn't be difficult, a copy paste of the code changing 2 or 3 things) 2) Maybe a proper sys_llistxattr, I've hardcoded the list, this is a little dirty 3) Find a converter file descriptor - filename or maybe code it. But I'm pretty sure googling a little we should find this. getattrlist doesn't have a file descriptor variant as getxattr. And I looked at the code, it seems that we don't even need such a function. It's only called in xattr.c under a lot of if/else branchs. Someone can confirm this? 4) Put the correct includes I also noticed that sys_lgetxattr can not be called twice if the buffer size is too small, because there is no offset management. Is this normal? When sys_lgetxattr returns a full buffer it is called with a bigger one trashing all the data already there? Shouldn't we correct this behaviour? Thanks for all that makes this project going on! Vitorio Machado Le 28 janv. 08 à 06:21, Matt McCutchen a écrit : On Sun, 2008-01-27 at 20:35 +0100, Vitorio Machado wrote: I've decided to implement resource fork from the carbon API. The code is not ready at all, but I've made a draft here: http:// shared.and.free.fr/sysxattrs_draft080127.c So all metadata attribute that can be accessed with getattrlist will be (finder info, flags, permissions, dates, etc). And particularly for the resource fork, that hopelessly can't be accessed this way, I'll implement it with the carbon framework. With something like this: 1) open the resource fork giving all args needed for the FSOpenFork function 2) copying the resource fork into the value buffer 3) closing all stuff correctly and giving to the upper layer the resource fork as if it was get from the getxattr I think things are in the right way. Comments about the carbon choice (I've never coded something using carbon) and the begin of implementation in the source code are as always welcome. I'm not a pro and there is maybe a simpler way to do this. So, please don't let me work uselessly if you know something I don't :) I looked at the draft code. The approach for the resource fork looks right, but I think a lot of the attributes you have shouldn't be included. There's no point in getting read-only attributes because they can't be set on the destination. Rsync already handles many of the other attributes other ways; it might eventually handle them through get/setattrlist for performance, but there's no point in exposing them now in the getxattr abstraction layer. I made the attached spreadsheet with the statuses of the 13 attributes listed as read/write as well as the resource fork; corrections are welcome. Mattmac-attrs.ods -- 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, Feb 07, 2008 at 10:51:34PM +0100, Vitorio Machado wrote: I also noticed that sys_lgetxattr can not be called twice if the buffer size is too small, because there is no offset management. Is this normal? The code calls sys_lgetxattr() once with a NULL pointer and a 0 length to ask for the size. Then, it calls it with a buffer large enough to hold the attribute. So, the best solution would be to make your code just ask the OS how big an item is when there is no buffer pointer. If that is not possible, it should be easy to cache an object in a static in your function and re-use it for a following call where the name matches. ..wayne.. -- 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
Thanks for the info, so I'll have to do an if/else and check manually the size when the buffer is NULL. It's not the case in the actual code. Any more reactions about what I've coded? Thanks, Vitorio Machado Le 7 févr. 08 à 23:33, Wayne Davison a écrit : On Thu, Feb 07, 2008 at 10:51:34PM +0100, Vitorio Machado wrote: I also noticed that sys_lgetxattr can not be called twice if the buffer size is too small, because there is no offset management. Is this normal? The code calls sys_lgetxattr() once with a NULL pointer and a 0 length to ask for the size. Then, it calls it with a buffer large enough to hold the attribute. So, the best solution would be to make your code just ask the OS how big an item is when there is no buffer pointer. If that is not possible, it should be easy to cache an object in a static in your function and re-use it for a following call where the name matches. ..wayne.. -- 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 Jan 26, 2008, at 10:43 PM, Matt McCutchen wrote: I poked around some more. Here is my current understanding of the xattr situation... You've got it exactly right. PS. Sorry to have gone silent wrt the mac port. I ended up solving my original problem another way and thus haven't done much with rsync since. -- 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
Thanks for all this info, it's very helpful to concentrate me on what is to be done and not distracting with details... Code will be much simpler with only 3 attributes to care about. I've just looked at the osx-create-time.diff (I know, you said me to read it many time ago...), things are much clearer on why an rsync name for creation date and how using getattrlist. If you think this model is ok, I will code OS X.3- in the same way to have an easier code to read/maintain as conventions are the same. Well, things seem to go on :) I don't think I will have time to work on this today, but if somebody wants, feel free to take my draft and do some work on it ( http:// shared.and.free.fr/sysxattrs_draft080127.c ). And you have maybe a CVS or SVN thing to share the code, I'm new in collective projects and don't really know about it, but I'm not opposed at all to create a central repository for this mini-project of patch to OS X.3-. Best regards, Vitorio Le 28 janv. 08 à 05:44, Matt McCutchen a écrit : On Sun, 2008-01-27 at 15:38 +0100, Vitorio Machado wrote: So I've started trying to put some code on sysxattrs.c. I've created another case as suggested by Matt: #elif HAVE_PRE_TIGER_OSX_ATTRS I would suggest creating a subcase inside HAVE_OSX_XATTRS instead of a completely separate case because both 10.3 and 10.4+ need the creation time exposure code that is currently in osx-create-time.diff . Well, should I put in this list all the attributes or only ressource fork related? I also see attributes like creation, modification, access date that can be retrieved by a stat call. Do rsync do this stat call for other attributes or do I have to copy this data to? In other words, which extended attributes are important to preserve? My preoccupation is with doing 2 times the same job, but also with compatibility with newer versions. I would like to patch it the best way possible (if there is no significant coding difference). For now, I suggest that you focus on the creation time, the resource fork, and the finder info; those seem to be the major things people care about that rsync doesn't already preserve other ways. For now, let's do it the dumb way and use a separate getattrlist call for each. In the future, for improved performance, we could look into using a single getattrlist per file to get both the stat data and all the Mac- specific stuff at once, or even getdirentriesattr to get names and attributes for everything in a directory at once. 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
Well, as I understood, what we have to do is to parse the xattr.c and
xattr.h codes and substitutes calls for getxattr() and setxattr() to
similar getattrlist() and setattrlist() from the man pages Matt gave us.
Someone knows how to get the sources from http://
hfsrsync.darwinports.com/ ? I wonder how it is patched and if we
couldn't get some code from there... Maybe they already done this
work we are going to do. But I only know how to install a port from
darwinports, not to get sources.
Le 27 janv. 08 à 00:14, Robert DuToit a écrit :
Matt,
I would be happy to implement and test any of these things on OS
10.3 thru 10.5. the only hitch is I am only applescript savvy with
a smattering of OBJ-c. so can help if someone tells me what to do,
what code to implement etc. But this is probably where Vitorio
comes in- he sounds eager to get something going. Rob
On Jan 26, 2008, at 4:43 PM, Matt McCutchen wrote:
On Sat, 2008-01-26 at 15:52 -0500, Matt McCutchen wrote:
Rsync is
unlikely to be able to manipulate xattrs on 10.3 unless we can
figure
out what the old API is and add it as another case in
lib/sysxattrs.{c,h} .
I poked around some more. Here is my current understanding of the
xattr
situation:
- All versions of Mac OS X support certain Mac-specific attributes,
including resource fork, finder flags, and creation time. The
getattrlist and setattrlist functions access most of these:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/
man2/getattrlist.2.html
http://developer.apple.com/documentation/Darwin/Reference/ManPages/
man2/setattrlist.2.html
- Mac OS 10.4+ supports arbitrarily named xattrs through the getxattr
interface. Its implementation of this interface also exposes most of
the Mac-specific attributes as xattrs with specific names, allowing
rsync to preserve them as it would any other xattr.
- Oddly, the creation time is not exposed at the 10.4+ getxattr
level.
Thus, osx-create-time.diff adds a special case at rsync's getxattr
abstraction level to expose the creation time (accessed via
{get,set}attrlist) as an xattr named com.apple.crtime96. This
name is
rsync-specific and was chosen by Wayne. It will be stored on non-Mac
filesystems to which Mac files have been copied, so we have to be
careful about changing it later.
- 10.3 does not support arbitrarily named xattrs and does not provide
the getxattr interface. To make rsync preserve the Mac-specific
attributes, we would need to write code to access each one
individually
using {get,set}attrlist, like osx-create-time.diff does for creation
times. Probably the most natural approach is to wire these up to
rsync's getxattr abstraction level using the same names by which they
are exposed by 10.4+. This way, rsync copies between 10.3 and
10.4 will
just work.
The operation of the current rsync getxattr abstraction layer to
read an
xattr named N can be described as follows (the top three lines coming
from osx-create-time.diff):
if (mac N == com.apple.crtime96)
getattrlist(ATTR_CMN_CRTIME);
else
getxattr(N);
To fully support Mac OS 10.3 attributes, we will need an extra
configure
test to distinguish 10.3 from 10.4+ and an abstraction layer like
this:
if (mac N == com.apple.crtime96)
getattrlist(ATTR_CMN_CRTIME);
else if (mac 10.4) {
if (N == com.apple.FinderInfo)
getattrlist(ATTR_CMN_FNDRINFO);
else if (N == com.apple.ResourceFork)
// I'm not sure of the API to access the resource fork.
// More cases here?
else
// No other xattrs exist.
} else
getxattr(N);
See also the following message by Wesley Terpstra for some related
ideas, including how attributes might interact with --fake-super:
http://lists.samba.org/archive/rsync/2007-October/018892.html
Please correct me if any of the above is wrong. And...does anyone
who
has a Mac feel like implementing this?
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
--
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
I finally could get it from http://archive.macosxlabs.org/rsyncx/
rsync-2.5.5.hfs.tgz
Will see if I can understand how they patched rsync 2.5.5 and if it's
a better idea to transport their patch to 3.0.0pre8 or to start one
from scratch with they precious informations from Matt.
If you have some ideas about all of this, please feel free to share.
I'm trying to find a solution but I'm not expert at all in rsync nor
patching.
Vitorio
PS: Sorry if you think I'm spamming. I try to not post too often, but
how we are many people on the problem, I think is important to share
experiences about it. If it annoy someone I'll stop posting so often.
Le 27 janv. 08 à 11:32, Vitorio Machado a écrit :
Well, as I understood, what we have to do is to parse the xattr.c
and xattr.h codes and substitutes calls for getxattr() and setxattr
() to similar getattrlist() and setattrlist() from the man pages
Matt gave us.
Someone knows how to get the sources from http://
hfsrsync.darwinports.com/ ? I wonder how it is patched and if we
couldn't get some code from there... Maybe they already done this
work we are going to do. But I only know how to install a port from
darwinports, not to get sources.
Le 27 janv. 08 à 00:14, Robert DuToit a écrit :
Matt,
I would be happy to implement and test any of these things on OS
10.3 thru 10.5. the only hitch is I am only applescript savvy with
a smattering of OBJ-c. so can help if someone tells me what to do,
what code to implement etc. But this is probably where Vitorio
comes in- he sounds eager to get something going. Rob
On Jan 26, 2008, at 4:43 PM, Matt McCutchen wrote:
On Sat, 2008-01-26 at 15:52 -0500, Matt McCutchen wrote:
Rsync is
unlikely to be able to manipulate xattrs on 10.3 unless we can
figure
out what the old API is and add it as another case in
lib/sysxattrs.{c,h} .
I poked around some more. Here is my current understanding of
the xattr
situation:
- All versions of Mac OS X support certain Mac-specific attributes,
including resource fork, finder flags, and creation time. The
getattrlist and setattrlist functions access most of these:
http://developer.apple.com/documentation/Darwin/Reference/
ManPages/man2/getattrlist.2.html
http://developer.apple.com/documentation/Darwin/Reference/
ManPages/man2/setattrlist.2.html
- Mac OS 10.4+ supports arbitrarily named xattrs through the
getxattr
interface. Its implementation of this interface also exposes
most of
the Mac-specific attributes as xattrs with specific names, allowing
rsync to preserve them as it would any other xattr.
- Oddly, the creation time is not exposed at the 10.4+ getxattr
level.
Thus, osx-create-time.diff adds a special case at rsync's getxattr
abstraction level to expose the creation time (accessed via
{get,set}attrlist) as an xattr named com.apple.crtime96. This
name is
rsync-specific and was chosen by Wayne. It will be stored on non-
Mac
filesystems to which Mac files have been copied, so we have to be
careful about changing it later.
- 10.3 does not support arbitrarily named xattrs and does not
provide
the getxattr interface. To make rsync preserve the Mac-specific
attributes, we would need to write code to access each one
individually
using {get,set}attrlist, like osx-create-time.diff does for creation
times. Probably the most natural approach is to wire these up to
rsync's getxattr abstraction level using the same names by which
they
are exposed by 10.4+. This way, rsync copies between 10.3 and
10.4 will
just work.
The operation of the current rsync getxattr abstraction layer to
read an
xattr named N can be described as follows (the top three lines
coming
from osx-create-time.diff):
if (mac N == com.apple.crtime96)
getattrlist(ATTR_CMN_CRTIME);
else
getxattr(N);
To fully support Mac OS 10.3 attributes, we will need an extra
configure
test to distinguish 10.3 from 10.4+ and an abstraction layer like
this:
if (mac N == com.apple.crtime96)
getattrlist(ATTR_CMN_CRTIME);
else if (mac 10.4) {
if (N == com.apple.FinderInfo)
getattrlist(ATTR_CMN_FNDRINFO);
else if (N == com.apple.ResourceFork)
// I'm not sure of the API to access the resource fork.
// More cases here?
else
// No other xattrs exist.
} else
getxattr(N);
See also the following message by Wesley Terpstra for some related
ideas, including how attributes might interact with --fake-super:
http://lists.samba.org/archive/rsync/2007-October/018892.html
Please correct me if any of the above is wrong. And...does
anyone who
has a Mac feel like implementing this?
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
--
To unsubscribe or change options: https://lists.samba.org/mailman/
listinfo/rsync
Before posting,
Re: Making rsync compile under Mac OS X 10.3.9 with extended attributes
On Sun, 2008-01-27 at 11:32 +0100, Vitorio Machado wrote:
Well, as I understood, what we have to do is to parse the xattr.c and
xattr.h codes and substitutes calls for getxattr() and setxattr() to
similar getattrlist() and setattrlist() from the man pages Matt gave us.
xattr.h and xattr.c access the xattr system calls via an abstraction
layer in lib/sysxattrs.h and lib/sysxattrs.c . Instead of modifying
xattr.h and xattr.c, you should modify the abstraction layer; that will
be much easier and cleaner.
Also remember that, since Mac OS before 10.4 doesn't support arbitrarily
named xattrs, only a few {get,set}xattr calls have {get,set}attrlist
equivalents, namely those that access com.apple.ResourceFork,
com.apple.FinderInfo, or com.apple.crtime96 (the rsync-specific name
for the creation time).
On Sun, 2008-01-27 at 11:49 +0100, Vitorio Machado wrote:
I finally could get it from http://archive.macosxlabs.org/rsyncx/
rsync-2.5.5.hfs.tgz
Will see if I can understand how they patched rsync 2.5.5 and if it's
a better idea to transport their patch to 3.0.0pre8 or to start one
from scratch with they precious informations from Matt.
Without offense to its author, that patched rsync 2.5.5 looks pretty
messy, especially because all of the attributes had to be implemented
ad-hoc. Let's start from scratch and reuse the nice xattr
infrastructure present in rsync 3.0.0pre8 by making the necessary
extensions to the abstraction layer.
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
I've looked at the source of rsync-2.5.5.hfs and unfortunately it isn't patched the same way. If you are curious about it, just look at the syscall.c in rsync-2.5.5, in particular code between #ifdef DARWIN and #endif /* DARWIN */ I can't understand very well the code, but it seems to copy the ressources fork with system calls to cp command. So I think the best way of patching is doing what Matt said (using getattrlist instead of getxattr in 10.3). For the way of recognizing the OS (pseudo-coded as mac 10.4), ./ configure gives target as powerpc-apple-darwin7.9.0 for 10.3.9, powerpc-apple-darwin8.11.0 for 10.4.11. darwinA.B.C represents Mac OS X 10.(A-4).B, so I think here is our way to create a flag like mac_bellow_tiger. But I don't know how to put this flag in the configure script, especially because it seems to be automatically generated, so would be better to patch the source than the result. Do someone knows how to do that? So my documentation phase is ended, I will concentrate my efforts now on coding something following Matt's example. Best regards, Vitorio -- 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 Sun, 2008-01-27 at 13:10 +0100, Vitorio Machado wrote: For the way of recognizing the OS (pseudo-coded as mac 10.4), ./ configure gives target as powerpc-apple-darwin7.9.0 for 10.3.9, powerpc-apple-darwin8.11.0 for 10.4.11. darwinA.B.C represents Mac OS X 10.(A-4).B, so I think here is our way to create a flag like mac_bellow_tiger. But I don't know how to put this flag in the configure script, especially because it seems to be automatically generated, so would be better to patch the source than the result. Do someone knows how to do that? The configure script is generated from configure.in. It looks like all you have to do is add an extra test inside the darwin* case on line 892 to check if $host_os matches darwin[4567].* and, if so, define an additional macro HAVE_PRE_TIGER_OSX_ATTRS. Then lib/sysxattrs.* can test #ifdef HAVE_PRE_TIGER_OSX_ATTRS. You also need to make sure that the configure script enables xattr support by default (really the 10.3-specific pseudo-xattr support) even though 10.3 fails all of the tests for the real xattr headers. Probably the way to do this is to add getattrlist to the list of functions on line 555 whose presence is tested and add it on line 920 as one of the functions whose presence indicates that xattrs are worth a try. 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 Sun, 2008-01-27 at 06:49 -0500, Matt McCutchen wrote:
Also remember that, since Mac OS before 10.4 doesn't support arbitrarily
named xattrs, only a few {get,set}xattr calls have {get,set}attrlist
equivalents, namely those that access com.apple.ResourceFork,
com.apple.FinderInfo, or com.apple.crtime96 (the rsync-specific name
for the creation time).
I take one third of that back. Based on the patched rsync 2.5.5, it
looks like the filesystem exposes the resource fork of a file F as a
file at the path F/rsrc. To perform a getxattr(F,
com.apple.ResourceFork), rsync will have to open and read F/rsrc,
not call getattrlist. (Supposedly the F/rsrc syntax is deprecated,
but rsync will only use it in Mac OS 10.3 and earlier, so we don't
care.)
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
Sorry about this question, I just realised that getxattr gets the name of the extended attribute as a parameter... So that is what I should put on the attrList. Carefully reading man is useful :/ Le 27 janv. 08 à 15:38, Vitorio Machado a écrit : First of all, thanks to Matt for all this help. It makes my job much easier :) So I've started trying to put some code on sysxattrs.c. I've created another case as suggested by Matt: #elif HAVE_PRE_TIGER_OSX_ATTRS And I'm trying to convert getxattr system calls to getattrlist. But I have some doubts, hope you can help me. As I understood the getxattr system call gives you ALL the extended attributes (in the limit of the size of the buffer that you given). In getattrlist you provides a list of which attributes you want... Well, should I put in this list all the attributes or only ressource fork related? I also see attributes like creation, modification, access date that can be retrieved by a stat call. Do rsync do this stat call for other attributes or do I have to copy this data to? In other words, which extended attributes are important to preserve? My preoccupation is with doing 2 times the same job, but also with compatibility with newer versions. I would like to patch it the best way possible (if there is no significant coding difference). Best regards, Vitorio PS: man pages for getxattr and getattrlist are http:// developer.apple.com/documentation/Darwin/Reference/Manpages/man2/ getxattr.2.html and http://developer.apple.com/documentation/Darwin/ Reference/ManPages/man2/getattrlist.2.html -- To unsubscribe or change options: https://lists.samba.org/mailman/ listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart- questions.html -- 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
Hi again...
Well, I started coding an interface for getattrlist but I can't find
any attribute in the list of the man page that seems to be the
Resource Fork. I think in mac pre10.4 there was another way to get
it, and it wasn't considered like an extended attribute. Someone have
more info on this?
Vitorio
Le 27 janv. 08 à 12:49, Matt McCutchen a écrit :
Also remember that, since Mac OS before 10.4 doesn't support
arbitrarily
named xattrs, only a few {get,set}xattr calls have {get,set}attrlist
equivalents, namely those that access com.apple.ResourceFork,
com.apple.FinderInfo, or com.apple.crtime96 (the rsync-specific
name
for the creation time).
--
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
Bad news:
The getattrlist function retrieves the metadata associated with a
file. The getxattr function, added in Mac OS X v10.4, retrieves
extended attributes
http://developer.apple.com/documentation/MacOSX/Conceptual/
universal_binary/universal_binary_tips/chapter_5_section_12.html
So getattrlist will work for metadata (finder info, type/creator,
etc), but not for the resource fork. Maybe that's why the 2.5.5
version patched used cp system calls.
I'm trying to find out now if there is more elegant way to do it
instead of cp the /rsrc fork. As always, your suggestions are welcome :)
Vitorio
Le 27 janv. 08 à 18:23, Vitorio Machado a écrit :
Hi again...
Well, I started coding an interface for getattrlist but I can't
find any attribute in the list of the man page that seems to be the
Resource Fork. I think in mac pre10.4 there was another way to get
it, and it wasn't considered like an extended attribute. Someone
have more info on this?
Vitorio
Le 27 janv. 08 à 12:49, Matt McCutchen a écrit :
Also remember that, since Mac OS before 10.4 doesn't support
arbitrarily
named xattrs, only a few {get,set}xattr calls have {get,set}attrlist
equivalents, namely those that access com.apple.ResourceFork,
com.apple.FinderInfo, or com.apple.crtime96 (the rsync-
specific name
for the creation time).
--
To unsubscribe or change options: https://lists.samba.org/mailman/
listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-
questions.html
--
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
Hi people, I've decided to implement resource fork from the carbon API. The code is not ready at all, but I've made a draft here: http:// shared.and.free.fr/sysxattrs_draft080127.c So all metadata attribute that can be accessed with getattrlist will be (finder info, flags, permissions, dates, etc). And particularly for the resource fork, that hopelessly can't be accessed this way, I'll implement it with the carbon framework. With something like this: 1) open the resource fork giving all args needed for the FSOpenFork function 2) copying the resource fork into the value buffer 3) closing all stuff correctly and giving to the upper layer the resource fork as if it was get from the getxattr I think things are in the right way. Comments about the carbon choice (I've never coded something using carbon) and the begin of implementation in the source code are as always welcome. I'm not a pro and there is maybe a simpler way to do this. So, please don't let me work uselessly if you know something I don't :) Best regards, Vitorio -- 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 Sun, 2008-01-27 at 15:38 +0100, Vitorio Machado wrote: So I've started trying to put some code on sysxattrs.c. I've created another case as suggested by Matt: #elif HAVE_PRE_TIGER_OSX_ATTRS I would suggest creating a subcase inside HAVE_OSX_XATTRS instead of a completely separate case because both 10.3 and 10.4+ need the creation time exposure code that is currently in osx-create-time.diff . Well, should I put in this list all the attributes or only ressource fork related? I also see attributes like creation, modification, access date that can be retrieved by a stat call. Do rsync do this stat call for other attributes or do I have to copy this data to? In other words, which extended attributes are important to preserve? My preoccupation is with doing 2 times the same job, but also with compatibility with newer versions. I would like to patch it the best way possible (if there is no significant coding difference). For now, I suggest that you focus on the creation time, the resource fork, and the finder info; those seem to be the major things people care about that rsync doesn't already preserve other ways. For now, let's do it the dumb way and use a separate getattrlist call for each. In the future, for improved performance, we could look into using a single getattrlist per file to get both the stat data and all the Mac-specific stuff at once, or even getdirentriesattr to get names and attributes for everything in a directory at once. 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 Sun, 2008-01-27 at 20:35 +0100, Vitorio Machado wrote: I've decided to implement resource fork from the carbon API. The code is not ready at all, but I've made a draft here: http:// shared.and.free.fr/sysxattrs_draft080127.c So all metadata attribute that can be accessed with getattrlist will be (finder info, flags, permissions, dates, etc). And particularly for the resource fork, that hopelessly can't be accessed this way, I'll implement it with the carbon framework. With something like this: 1) open the resource fork giving all args needed for the FSOpenFork function 2) copying the resource fork into the value buffer 3) closing all stuff correctly and giving to the upper layer the resource fork as if it was get from the getxattr I think things are in the right way. Comments about the carbon choice (I've never coded something using carbon) and the begin of implementation in the source code are as always welcome. I'm not a pro and there is maybe a simpler way to do this. So, please don't let me work uselessly if you know something I don't :) I looked at the draft code. The approach for the resource fork looks right, but I think a lot of the attributes you have shouldn't be included. There's no point in getting read-only attributes because they can't be set on the destination. Rsync already handles many of the other attributes other ways; it might eventually handle them through get/setattrlist for performance, but there's no point in exposing them now in the getxattr abstraction layer. I made the attached spreadsheet with the statuses of the 13 attributes listed as read/write as well as the resource fork; corrections are welcome. Matt mac-attrs.ods Description: application/vnd.oasis.opendocument.spreadsheet -- 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
Hello, It's cool to see that I'm not the only one trying this! @Matt: I'm not in front of the 10.3 computer, but I'm almost sure that the --enable-xattr-support option makes the make want to compile acls.c giving the same errors. If the problem is only data structure and constant definitions, wouldn't it be possible to trick the compilation by addind a header with it for Mac 10.3 computers? But if it uses fonctions declared on those headers it doesn't found, it's more complicated :/ Best regards, Vitorio Le 26 janv. 08 à 05:13, Matt McCutchen a écrit : On Fri, 2008-01-25 at 21:38 -0500, Robert DuToit wrote: I reinstalled developer tools again on OS10.3.2 and ran make again and this time and saw more action but a lot of errors such as the one mentioned by Vitorio: error: `ACL_TYPE_DEFAULT' undeclared (first use in this function) Please try again with: ./configure --disable-acl-support --enable-xattr-support 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 -- 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
Hi Matt, I tried ./configure --disable-acl-support --enable-xattr-support and got `XATTR_NOFOLLOW' undeclared (first use in this function) so then /configure --disable-acl-support --disable-xattr-support which worked then added patches patch -p1 patches/flags.diff patch -p1 patches/osx-create-time.diff ./configure --disable-acl-support --enable-xattr-support make OK this time. Then I tried some simple tests on OS10.3X mypathto/rsync -a --fileflags testdir destdir (no AX of course!) It works and flags seem to work at least for locked files. Creation time was not saved though. any thoughts on xattrs or creation dates? Quite a few people still ask me to make support scripts on OS 10.3.9. Acls probably not such an issue on OS 10.3 and earlier. Thanks Rob complete output from ./configure --disable-acl-support --enable-xattr- support: make Last login: Sat Jan 26 05:41:50 on console Welcome to Darwin! Robert-DuToits-Computer:~ robertdutoit$ cd rsync-3.0.0pre8 Robert-DuToits-Computer:~/rsync-3.0.0pre8 robertdutoit$ ./configure -- disable-acl-support --enable-xattr-support configure.sh: Configuring rsync 3.0.0pre8 checking build system type... powerpc-apple-darwin7.2.0 checking host system type... powerpc-apple-darwin7.2.0 checking target system type... powerpc-apple-darwin7.2.0 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for a BSD-compatible install... /usr/bin/install -c checking for gcc option to accept ISO C99... -std=gnu99 checking for gcc -std=gnu99 option to accept ISO Standard C... (cached) -std=gnu99 checking whether to include debugging symbols... yes checking for remsh... 0 checking for yodl2man... 0 checking the group for user nobody... nobody checking for broken largefile support... no checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking ipv6 stack type... kame checking for library containing getaddrinfo... none required checking whether to call shutdown on all sockets... no checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether byte ordering is bigendian... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking whether time.h and sys/time.h may both be included... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/unistd.h usability... yes checking sys/unistd.h presence... yes checking for sys/unistd.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking compat.h usability... no checking compat.h presence... no checking for compat.h... no checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking ctype.h usability... yes checking ctype.h presence... yes checking for ctype.h... yes checking for sys/wait.h... (cached) yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/filio.h usability... yes checking sys/filio.h presence... yes checking for sys/filio.h... yes checking for string.h... (cached) yes checking for stdlib.h... (cached) yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/mode.h usability... no checking sys/mode.h presence... no checking for sys/mode.h... no checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking sys/attr.h usability... yes checking sys/attr.h presence... yes checking for sys/attr.h... yes checking glob.h usability... yes checking glob.h
Re: Making rsync compile under Mac OS X 10.3.9 with extended attributes
Hi Matt, a footnote: Back on OS 10.5.1, I ran backup bouncer on the compiled OS10.3 rsync (without ACL, Xattrs enabled) Verifying:basic-permissions ... ok Verifying: timestamps ... Sub-test:modification time ... ok ok Verifying: symlinks ... ok Verifying:symlink-ownership ... FAIL Verifying:hardlinks ... FAIL Verifying: resource-forks ... FAIL Verifying: finder-flags ... FAIL Verifying: finder-locks ... ok Verifying:creation-date ... FAIL Verifying:bsd-flags ... ok Verifying: extended-attrs ... Sub-test: on files ... FAIL Sub-test: on directories ... FAIL Sub-test: on symlinks ... FAIL FAIL Verifying: access-control-lists ... Sub-test: on files ... FAIL Sub-test: on dirs ... FAIL FAIL Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... FAIL Sub-test: lots of metadata ... FAIL FAIL not so good... not sure the results would look any better under 10.3. And yet fifo and devices came up shining (the only ones that didn't on the 10.5 build)! Thanks, Rob On Jan 25, 2008, at 11:13 PM, Matt McCutchen wrote: On Fri, 2008-01-25 at 21:38 -0500, Robert DuToit wrote: I reinstalled developer tools again on OS10.3.2 and ran make again and this time and saw more action but a lot of errors such as the one mentioned by Vitorio: error: `ACL_TYPE_DEFAULT' undeclared (first use in this function) Please try again with: ./configure --disable-acl-support --enable-xattr-support 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
Sorry, I've misread your mail. But don't give up, I think that if we correct the headers in 10.3, we have a chance to make it compile. We should look at the ACL and xattr code and see if there are only constant and variable definition on the system headers that are not found in 10.3 or if it's more deep lied to the 10.4 API. In this case it represents much more work, but we have the chance that the basic system layer (Darwin) of 10.4 is released open source... So maybe we could take some code from there to have our xattr on 10.3... So, if nobody have a better idea, I think we should proceed like this: 1) Look on ACL and xattr code to understand what code they expect from the system 2a) If it's just a definition stuff (variable declaration, constants, etc) we can try a workaround of the configure script or something to put another header for 10.3 systems giving all those stuff that aren't built-in in the system headers. This shouldn't represent a lot of work 2b) If xattr and ACL code expect to use system fonctions, it won't be so simple... We can try patching the 10.3 system with some code of Darwin 8 (system code of 10.4 OS) hoping not have to go too deep, but just getting 1 or 2 files from it. 3) compile rsync with xattr support successfully with our little hacking. I will start looking into the code to try to figure out xattr and acl dependencies on the system. But I don't have Mac OS 10.3 here, only 10.4. It will be impossible for me to make any test today. Chin up, we can do it! Vitorio Le 26 janv. 08 à 13:47, Robert DuToit a écrit : Hi Vitorio, Well, actually, it only compiles only with --disable-acl-support -- disable-xattr-support. which kind of defeats the whole purpose since xattrs are out of the picture. Rob On Jan 26, 2008, at 7:24 AM, Vitorio Machado wrote: Interesting, So patched rsync compiles with --disable-acl-support --enable- xattr-support. Can you give an output of rsync --version to see if it says that xattr is enabled on capabilities? Best regards, Vitorio Le 26 janv. 08 à 12:36, Robert DuToit a écrit : Hi Matt, I tried ./configure --disable-acl-support --enable-xattr-support and got `XATTR_NOFOLLOW' undeclared (first use in this function) so then /configure --disable-acl-support --disable-xattr-support which worked then added patches patch -p1 patches/flags.diff patch -p1 patches/osx-create-time.diff ./configure --disable-acl-support --enable-xattr-support make OK this time. Then I tried some simple tests on OS10.3X mypathto/rsync -a --fileflags testdir destdir (no AX of course!) It works and flags seem to work at least for locked files. Creation time was not saved though. any thoughts on xattrs or creation dates? Quite a few people still ask me to make support scripts on OS 10.3.9. Acls probably not such an issue on OS 10.3 and earlier. Thanks Rob -- 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
Well, it seems that we just use definitions from the system acl.h So putting the acl.h attached into /Developer/SDKs/MacOSX10.3.9.sdk/ usr/include/sys/ should correct first errors. I'm still studying the code to see if it needs other changes. acl.h Description: Binary data Le 26 janv. 08 à 19:44, Robert DuToit a écrit : Hi Vitorio, This is a bit out of my league. I've done some applescript applications including backuplist+ which rsync 3 has improved a great deal. I was hoping to make it backwards compatible to 10.3X so it would be great if we can do something to improve the xattrs and or ACL's. If you saw my other post, I also found that OSX creation dates aren't saved either with the build I did on 10.3 even with the patch for that I have little experience with OBJ-C (though I use lots of call method) or C etc so you would have to see if you can figure that out. Keep me informed. Anything I can do though , let me know. Thanks, Rob On Jan 26, 2008, at 9:38 AM, Vitorio Machado wrote: Sorry, I've misread your mail. But don't give up, I think that if we correct the headers in 10.3, we have a chance to make it compile. We should look at the ACL and xattr code and see if there are only constant and variable definition on the system headers that are not found in 10.3 or if it's more deep lied to the 10.4 API. In this case it represents much more work, but we have the chance that the basic system layer (Darwin) of 10.4 is released open source... So maybe we could take some code from there to have our xattr on 10.3... So, if nobody have a better idea, I think we should proceed like this: 1) Look on ACL and xattr code to understand what code they expect from the system 2a) If it's just a definition stuff (variable declaration, constants, etc) we can try a workaround of the configure script or something to put another header for 10.3 systems giving all those stuff that aren't built-in in the system headers. This shouldn't represent a lot of work 2b) If xattr and ACL code expect to use system fonctions, it won't be so simple... We can try patching the 10.3 system with some code of Darwin 8 (system code of 10.4 OS) hoping not have to go too deep, but just getting 1 or 2 files from it. 3) compile rsync with xattr support successfully with our little hacking. I will start looking into the code to try to figure out xattr and acl dependencies on the system. But I don't have Mac OS 10.3 here, only 10.4. It will be impossible for me to make any test today. Chin up, we can do it! Vitorio Le 26 janv. 08 à 13:47, Robert DuToit a écrit : Hi Vitorio, Well, actually, it only compiles only with --disable-acl-support --disable-xattr-support. which kind of defeats the whole purpose since xattrs are out of the picture. Rob On Jan 26, 2008, at 7:24 AM, Vitorio Machado wrote: Interesting, So patched rsync compiles with --disable-acl-support --enable- xattr-support. Can you give an output of rsync --version to see if it says that xattr is enabled on capabilities? Best regards, Vitorio Le 26 janv. 08 à 12:36, Robert DuToit a écrit : Hi Matt, I tried ./configure --disable-acl-support --enable-xattr-support and got `XATTR_NOFOLLOW' undeclared (first use in this function) so then /configure --disable-acl-support --disable-xattr-support which worked then added patches patch -p1 patches/flags.diff patch -p1 patches/osx-create-time.diff ./configure --disable-acl-support --enable-xattr-support make OK this time. Then I tried some simple tests on OS10.3X mypathto/rsync -a --fileflags testdir destdir (no AX of course!) It works and flags seem to work at least for locked files. Creation time was not saved though. any thoughts on xattrs or creation dates? Quite a few people still ask me to make support scripts on OS 10.3.9. Acls probably not such an issue on OS 10.3 and earlier. Thanks Rob -- To unsubscribe or change options: https://lists.samba.org/mailman/ listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart- questions.html -- 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 Sat, 2008-01-26 at 06:36 -0500, Robert DuToit wrote:
I tried
./configure --disable-acl-support --enable-xattr-support
and got
`XATTR_NOFOLLOW' undeclared (first use in this function)
Based on the Apple's man page for getxattr [1], it looks like Mac OS X
did not gain support for the standardish xattr API (getxattr, etc.)
until version 10.4. I'm not sure what API (if any) was provided to
access xattrs before then. (Google's top result for mac os 10.3
extended attributes is this thread; that isn't a good sign.) Rsync is
unlikely to be able to manipulate xattrs on 10.3 unless we can figure
out what the old API is and add it as another case in
lib/sysxattrs.{c,h} . (You can try using 10.4 headers, but you'll
probably get a link error that the functions aren't present.)
[1]
http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man2/getxattr.2.html
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 Sat, 2008-01-26 at 15:52 -0500, Matt McCutchen wrote:
Rsync is
unlikely to be able to manipulate xattrs on 10.3 unless we can figure
out what the old API is and add it as another case in
lib/sysxattrs.{c,h} .
I poked around some more. Here is my current understanding of the xattr
situation:
- All versions of Mac OS X support certain Mac-specific attributes,
including resource fork, finder flags, and creation time. The
getattrlist and setattrlist functions access most of these:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/getattrlist.2.html
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/setattrlist.2.html
- Mac OS 10.4+ supports arbitrarily named xattrs through the getxattr
interface. Its implementation of this interface also exposes most of
the Mac-specific attributes as xattrs with specific names, allowing
rsync to preserve them as it would any other xattr.
- Oddly, the creation time is not exposed at the 10.4+ getxattr level.
Thus, osx-create-time.diff adds a special case at rsync's getxattr
abstraction level to expose the creation time (accessed via
{get,set}attrlist) as an xattr named com.apple.crtime96. This name is
rsync-specific and was chosen by Wayne. It will be stored on non-Mac
filesystems to which Mac files have been copied, so we have to be
careful about changing it later.
- 10.3 does not support arbitrarily named xattrs and does not provide
the getxattr interface. To make rsync preserve the Mac-specific
attributes, we would need to write code to access each one individually
using {get,set}attrlist, like osx-create-time.diff does for creation
times. Probably the most natural approach is to wire these up to
rsync's getxattr abstraction level using the same names by which they
are exposed by 10.4+. This way, rsync copies between 10.3 and 10.4 will
just work.
The operation of the current rsync getxattr abstraction layer to read an
xattr named N can be described as follows (the top three lines coming
from osx-create-time.diff):
if (mac N == com.apple.crtime96)
getattrlist(ATTR_CMN_CRTIME);
else
getxattr(N);
To fully support Mac OS 10.3 attributes, we will need an extra configure
test to distinguish 10.3 from 10.4+ and an abstraction layer like this:
if (mac N == com.apple.crtime96)
getattrlist(ATTR_CMN_CRTIME);
else if (mac 10.4) {
if (N == com.apple.FinderInfo)
getattrlist(ATTR_CMN_FNDRINFO);
else if (N == com.apple.ResourceFork)
// I'm not sure of the API to access the resource fork.
// More cases here?
else
// No other xattrs exist.
} else
getxattr(N);
See also the following message by Wesley Terpstra for some related
ideas, including how attributes might interact with --fake-super:
http://lists.samba.org/archive/rsync/2007-October/018892.html
Please correct me if any of the above is wrong. And...does anyone who
has a Mac feel like implementing this?
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 Sat, 2008-01-26 at 16:43 -0500, Matt McCutchen wrote:
if (mac N == com.apple.crtime96)
getattrlist(ATTR_CMN_CRTIME);
else if (mac 10.4) {
if (N == com.apple.FinderInfo)
getattrlist(ATTR_CMN_FNDRINFO);
else if (N == com.apple.ResourceFork)
// I'm not sure of the API to access the resource fork.
// More cases here?
else
// No other xattrs exist.
} else
getxattr(N);
Also, this would be a good opportunity to try to understand why the
current creation-time code slows rsync down considerably and avoid the
performance problem in the new code.
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
Matt,
I would be happy to implement and test any of these things on OS 10.3
thru 10.5. the only hitch is I am only applescript savvy with a
smattering of OBJ-c. so can help if someone tells me what to do, what
code to implement etc. But this is probably where Vitorio comes in-
he sounds eager to get something going. Rob
On Jan 26, 2008, at 4:43 PM, Matt McCutchen wrote:
On Sat, 2008-01-26 at 15:52 -0500, Matt McCutchen wrote:
Rsync is
unlikely to be able to manipulate xattrs on 10.3 unless we can figure
out what the old API is and add it as another case in
lib/sysxattrs.{c,h} .
I poked around some more. Here is my current understanding of the
xattr
situation:
- All versions of Mac OS X support certain Mac-specific attributes,
including resource fork, finder flags, and creation time. The
getattrlist and setattrlist functions access most of these:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/getattrlist.2.html
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/setattrlist.2.html
- Mac OS 10.4+ supports arbitrarily named xattrs through the getxattr
interface. Its implementation of this interface also exposes most of
the Mac-specific attributes as xattrs with specific names, allowing
rsync to preserve them as it would any other xattr.
- Oddly, the creation time is not exposed at the 10.4+ getxattr level.
Thus, osx-create-time.diff adds a special case at rsync's getxattr
abstraction level to expose the creation time (accessed via
{get,set}attrlist) as an xattr named com.apple.crtime96. This
name is
rsync-specific and was chosen by Wayne. It will be stored on non-Mac
filesystems to which Mac files have been copied, so we have to be
careful about changing it later.
- 10.3 does not support arbitrarily named xattrs and does not provide
the getxattr interface. To make rsync preserve the Mac-specific
attributes, we would need to write code to access each one
individually
using {get,set}attrlist, like osx-create-time.diff does for creation
times. Probably the most natural approach is to wire these up to
rsync's getxattr abstraction level using the same names by which they
are exposed by 10.4+. This way, rsync copies between 10.3 and 10.4
will
just work.
The operation of the current rsync getxattr abstraction layer to
read an
xattr named N can be described as follows (the top three lines coming
from osx-create-time.diff):
if (mac N == com.apple.crtime96)
getattrlist(ATTR_CMN_CRTIME);
else
getxattr(N);
To fully support Mac OS 10.3 attributes, we will need an extra
configure
test to distinguish 10.3 from 10.4+ and an abstraction layer like
this:
if (mac N == com.apple.crtime96)
getattrlist(ATTR_CMN_CRTIME);
else if (mac 10.4) {
if (N == com.apple.FinderInfo)
getattrlist(ATTR_CMN_FNDRINFO);
else if (N == com.apple.ResourceFork)
// I'm not sure of the API to access the resource fork.
// More cases here?
else
// No other xattrs exist.
} else
getxattr(N);
See also the following message by Wesley Terpstra for some related
ideas, including how attributes might interact with --fake-super:
http://lists.samba.org/archive/rsync/2007-October/018892.html
Please correct me if any of the above is wrong. And...does anyone who
has a Mac feel like implementing this?
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
Hi Again, I reinstalled developer tools again on OS10.3.2 and ran make again and this time and saw more action but a lot of errors such as the one mentioned by Vitorio: error: `ACL_TYPE_DEFAULT' undeclared (first use in this function) Thanks, Rob D Here is the whole output from make: rsync 3.0.0pre8 configuration successful Robert-DuToits-Computer:~/rsync-3.0.0pre8 robertdutoit$ make gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c flist.c -o flist.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c rsync.c -o rsync.o rsync.c: In function `set_file_attrs': rsync.c:342: warning: unused parameter `fnamecmp' gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c generator.c -o generator.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c receiver.c -o receiver.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c cleanup.c -o cleanup.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c sender.c -o sender.o sender.c: In function `write_ndx_and_attrs': sender.c:150: warning: unused parameter `fname' sender.c:150: warning: unused parameter `file' gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c exclude.c -o exclude.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c util.c -o util.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c main.c -o main.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c checksum.c -o checksum.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c match.c -o match.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c syscall.c -o syscall.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c log.c -o log.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c backup.c -o backup.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c options.c -o options.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c io.c -o io.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c compat.c -o compat.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c hlink.c -o hlink.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c token.c -o token.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c uidlist.c -o uidlist.o uidlist.c: In function `match_uid': uidlist.c:210: warning: comparison between signed and unsigned uidlist.c: In function `match_gid': uidlist.c:222: warning: comparison between signed and unsigned uidlist.c:226: warning: comparison between signed and unsigned uidlist.c: In function `add_uid': uidlist.c:249: warning: comparison between signed and unsigned uidlist.c: In function `add_gid': uidlist.c:267: warning: comparison between signed and unsigned gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c socket.c -o socket.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c hashtable.c -o hashtable.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c fileio.c -o fileio.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c batch.c -o batch.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c clientname.c -o clientname.o clientname.c: In function `compare_addrinfo_sockaddr': clientname.c:269: warning: int format, size_t arg (arg 4) gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c chmod.c -o chmod.o gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c acls.c -o acls.o In file included from acls.c:23: lib/sysacls.h:288: error: parse error before the_acl lib/sysacls.h:289: error: parse error before entry_d lib/sysacls.h:290: error: parse error before entry lib/sysacls.h:291: error: parse error before sys_acl_get_file lib/sysacls.h:291: error: parse error before acl_type_t lib/sysacls.h:291: warning: type defaults to `int' in declaration of `sys_acl_get_file' lib/sysacls.h:291: warning: data definition has no type or storage class lib/sysacls.h:292: error: parse error before sys_acl_get_fd lib/sysacls.h:292: warning: type defaults to `int' in declaration of `sys_acl_get_fd' lib/sysacls.h:292: warning: data definition has no type or storage class lib/sysacls.h:293: error: parse error before sys_acl_init lib/sysacls.h:293: warning: type defaults to `int' in declaration of `sys_acl_init' lib/sysacls.h:293: warning: data definition has no type or storage class lib/sysacls.h:294: error: parse error before '*' token lib/sysacls.h:295: error: parse error before entry lib/sysacls.h:296: error: parse error before entry lib/sysacls.h:297: error: parse error before theacl lib/sysacls.h:298: error: parse error before acl_type_t lib/sysacls.h:299: error: parse error before acl_t lib/sysacls.h:301: error: parse error before the_acl acls.c:81: error: parse error before acl_t acls.c:81:
Re: Making rsync compile under Mac OS X 10.3.9 with extended attributes
On Fri, 2008-01-25 at 21:38 -0500, Robert DuToit wrote: I reinstalled developer tools again on OS10.3.2 and ran make again and this time and saw more action but a lot of errors such as the one mentioned by Vitorio: error: `ACL_TYPE_DEFAULT' undeclared (first use in this function) Please try again with: ./configure --disable-acl-support --enable-xattr-support 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
Hi all, Somewhat along the same lines, I wanted to see if rsync 3 would work on Mac OS10.3X so I made a test partition and installed 10.3.2 on it ( no updates around). I then installed xcode 1.5 and with a fresh copy of rsync 3.0.0pre8 and tried ./configure which worked fine. When I tried make however I got the following error: Robert-DuToits-Computer:~/rsync-3.0.0pre8 robertdutoit$ make perl ./mkproto.pl ./*.c ./lib/compat.c Failed to create rounding.h! make: *** [rounding.h] Error 1 Does anyone have an idea how to make this work or if anyone has had success with OS10.3X and rsync 3? Thanks, Rob DuToit On Jan 25, 2008, at 11:45 AM, Vitorio Machado wrote: Le 24 janv. 08 à 16:30, Matt McCutchen a écrit : 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 First of all, thanks for your interest in my problem. I will post precise error repport next week, I'm not at work at the moment. The problem is that apparently xattr code depends on ACL code. But Mac OS X 10.3.9 doesn't have the needed API (gcc doesn't find headers about ACL code in the system). On a fresh downloaded source of rsync 3.0.0pre8 I've tried: 1) ./configure - configuration completes fine without error make - error on acl header as described (will report the precise error next week) 2) ./configure --disable-acl-support - configuration completes without error make - compilation goes just fine ./rsync --version - indicates in capabilities NO ACL and NO xattr support, so disabling ACL I've also disabled xattr (what I do need because the purpose is to backup mac files that are rich on ressource forks...) 3) ./configure --disable-acl-support --enable-xattr-support - configuration completes without error make - same acl error as in point number 1. This made me conclude the xattr code automatically activates the ACL support. And as ACL doesn't compile on 10.3 it seems it will not possible to have xattr on 10.3. Please say me that I'm wrong and that there's a way to trick it. Perhaps a patch like the one of RsyncX, http://www.quesera.com/reynhout/misc/rsync+hfsmode/ , or http://home.onthenet.com.au/~q/rsync/ , but applied to the last release. Note that I don't care so much about compability of the 10.3 rsync I'll get and other versions. The 10.3 rsync I want to compile doesn't need to talk with a rsync server, the backup will be done locally on a HFS+ volume. All I want is a fast incremental algorithm that preserve all the information (data and ressource fork basically, permissions, dates, etc would be fine but aren't mandatory) while making a copy. I can't use RsyncX version of rsync because it have an annoying double free bug. The version found at http://home.onthenet.com.au/~q/rsync/ is compiled 10.4+ only. I didn't tried to compile it on 10.3, will try it next week. http://www.quesera.com/reynhout/misc/rsync +hfsmode/ patch approach doesn't seem the good one for me, I don't want my files to be encoded as AppleDouble. And all those patch aren't official. It would be a lot easier to track bugs and get it progressing if it was the official rsync way to handle xattr. Don't you think it's the better approach?-- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- 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: 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
