Making rsync compile under Mac OS X 10.3.9 with extended
v.machado at permanence-informatique.fr
Thu Feb 7 21:51:34 GMT 2008
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/
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
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
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
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!
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://
>> 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
>> 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
> 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
> with the statuses of the 13 attributes listed as read/write as well as
> the resource fork; corrections are welcome.
More information about the rsync