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: Chris Suter <email@hidden>
- Date: Thu, 24 Apr 2008 12:59:29 +1000
On 24/04/2008, at 11:53 AM, Daniel DeCovnick wrote:
I'm pretty sure the resource fork size limits are rather large... EV
Nova's data files, in which everything is stored in the resource
fork, go up to 13.8 MB. Also, it's a definite advantage that the
resource fork is well-documented. That's more than one can say for
xattrs, which are best documented in the OSXBook over a grand total
of 3 pages.
The limits for resource forks are the same as for data forks. On HFS+
file-systems, they're stored in the same way as data forks are,
whereas extended attributes are stored in the attributes file. You can
still access the resource forks as if they were extended attributes.
I don't think it does... doesn't NTFS have support for arbitrary
named forks as well?
At least to the point that it doesn't overwrite other forks when the
data fork is written to? I mean, Windows can't read or write to
them, AFAIK, but the low-level read/write routines should preserve
it. I may be completely off base here, as I think I'm quoting a blog
post, which may or may not have been a wishlist for Windows
behavior. :-p
NTFS does have support fro arbitrary named forks, but whether or not
they're used depends on the implementation used to write them to an
NTFS system. When OS X copies files with resource forks to file-
systems that don't have support for resource-forks, I believe it
creates an additional hidden file to store the data. The problem with
these hidden files is that only OS X knows about them and so they'll
not follow the file if you copy them using any other system. I don't
know whether the SMB or read/write NTFS implementations used on OS X
have proper support for resource forks (I doubt it). It doesn't look
like the read-only NTFS implementation on OS X does. Sending files via
e-mails doesn't work. FAT file-systems obviously don't.
Unfortunately, as Uli pointed out, it's no longer unique if the file
is duplicated. So I think that approach is out.
Furthermore, it doesn't follow the file which was the original design
goal.
Going back to the original question, I personally think that the best
thing to do is to just create another file and educate the user.
Extended attributes and resource forks are all very nice but most
users don't understand what they are and they just don't interoperate
nicely with other systems.
You can probably improve the user experience on OS X by storing the
Catalog ID (as well as other details) of the file so that if the two
files get separated you can easily find where it's moved to (assuming
it's on the same file-system).
- Chris
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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