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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
