Am 23.04.2008 um 09:43 schrieb Daniel DeCovnick <[EMAIL PROTECTED]>:
On Apr 23, 2008, at 2:07 AM, Jens Alfke wrote:
On 22 Apr '08, at 10:21 PM, Daniel DeCovnick wrote:
Through a lot of thought experiments, I've come to the conclusion
that the best place to save this sort of thing would be in the
resource fork of the file being opened, but I could be totally off
the mark there, and it's certainly an unorthodox thing to do.
It would have been the right thing to do ten years ago. But these
days resource forks are definitely a legacy feature and it would be
a bad idea to write new software that relies on them.
Have you looked at Extended Attributes? They're kind of the moral
equivalent of resources, but they're newer, lighter-weight and
better integrated into the filesystem. I don't know if there's any
in-depth documentation, but you can start by reading the man pages
for getxattr, setxattr, et al.
Thanks for the suggestion. I've just looked through them now, as well
as at the OSXBook (Mac OS X Internals: A Systems Approach by Amit
Singh) info on that. In theory it looks good, but it's somewhat
confusing. It looks like, at least in 10.4, except for the resource
fork which is mapped as a fake xattr, you can only have inline
attributes, with a length limit of 3802 bytes, and it would be quite
common for my data to be significantly larger than that. Does anyone
know if that's changed for 10.5?
Depending on your semantics you could always just save a UUID in an
extended attribute and then associate that with your own storage
mechanism. That should always fit the size limitations.
To be more safe/compatible you could actually save the UUID as an
extended attribute as well in a resource. When reading use either and
reconsruct the missing one if necessary and possible.
HTH
Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
Note: I read this list in digest mode!
Send me a private copy for faster responses.
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
