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.
Matt<mac-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
