Re: Resource Fork - is this a good use/the right thing to do?
Re: Resource Fork - is this a good use/the right thing to do?
- Subject: Re: Resource Fork - is this a good use/the right thing to do?
- From: "Adam R. Maxwell" <email@hidden>
- Date: Wed, 23 Apr 2008 06:41:02 -0700
On Apr 23, 2008, at 12:41 AM, Daniel DeCovnick wrote:
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?
The limits aren't very well documented (or implemented), but you can
avoid the limit by splitting it into multiple attributes.
We save notes as extended attributes in Skim; this link is to a BSD
licensed NSFileManager category for writing arbitrarily sized NSData
as extended attributes by compressing it and then splitting it up if
needed.
http://skim-app.svn.sourceforge.net/viewvc/*checkout*/skim-app/trunk/NSFileManager_ExtendedAttributes.m
It works great on HFS+, but there are some caveats:
- creating a zip archive in Finder will destroy EA
- creating a disk image of a file with hdiutil will destroy EA under
some conditions
- asr may lose EA (we had at least one report of install+migration
failing)
- various filesystems (e.g. AFP) have different size limits than HFS+
and IIRC the return value of the setxattr function won't tell you it
failed in this case
Lack of filesystem support will bite you with resource forks as well,
but the first two are fixed in 10.5. It's still cleaner than messing
with resource fork code, IMO, and for the common case it works very
well.
--
adam
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden