Cocoa stripping resource forks: does Jaguar fix?
Cocoa stripping resource forks: does Jaguar fix?
- Subject: Cocoa stripping resource forks: does Jaguar fix?
- From: Kirk Kerekes <email@hidden>
- Date: Mon, 1 Jul 2002 16:40:12 -0500
Most Cocoa coders are (or should be) aware that several Cocoa features
(notably NSFileWrapper and thus NSPasteBoard's NSFileContentsPboardType)
blithely strip the resource fork off of any file unlucky enough to be
contained by them.
This is, of course, totally unacceptable in the HFS+ Classic/carbon/Cocoa
blended environment that OSX is used in. It means that otherwise competent
apps like TextEdit will _silently_ discard user data, which is pretty hard
to justify.
If you want an instant demo of this, open Internet Explorer, go to some
page, and then drag the contents of the address bar to the desktop. This
creates a ".webloc" location file. You can double-click on it, and IE will
open to that URL. (Dragging the "@" next to the address bar products a
different file type, which is also mangled by Cocoa, so take your pick.)
Now open a TextEdit Rich Text document, and drag the .webloc file to the
document. TextEdit will happily accept the drag, and show the icon -- but
it has in the process stripped all the contents out of the file, because IE
puts the URL in a resource in the resource fork.
Yeah, yeah. They shouldn't be doing that. But Cocoa shouldn't be silently
stripping it off, either. And every user migrating from Classic to X has an
HD full of items which will be damaged fatally by having the resource-fork
stripped off.
So, my question is -- does Jaguar, or any "in development" subsequent
version of OSX, fix this problem where it needs to be fixed -- inside
Cocoa?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.