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
