Making rsync compile under Mac OS X 10.3.9 with extended attributes

Vitorio Machado v.machado at permanence-informatique.fr
Sun Jan 27 10:49:11 GMT 2008


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, read: http://www.catb.org/~esr/faqs/smart- 
> questions.html



More information about the rsync mailing list