Re: creating a resource fork and writing raw bytes to it
Re: creating a resource fork and writing raw bytes to it
- Subject: Re: creating a resource fork and writing raw bytes to it
- From: Mike Fischer <email@hidden>
- Date: Thu, 22 May 2008 07:09:55 +0200
Am 22.05.2008 um 06:11 schrieb Charles Srstka:
On May 21, 2008, at 11:11 AM, Mike Fischer wrote:
There are hacks that rely on special pathnames to access the
resource fork of a file. (Something like /path/to/file/..namedfork/
rsrc) But I would not recommend using them as there is no
guarantee that they will continue to work in the future (or even
now in the context of Cocoa file operations). Also they might only
work on certain volume formats.
I suppose I could end up eating my words, but I'd be surprised
if ..namedfork/rsrc went away given that doing so would break a
really huge number of applications at this point, the fact that
it's currently the only way to access a resource fork from Cocoa/
POSIX without using Carbon calls, and the fact that Carbon seems to
be becoming deprecated these days.
As I understand it only the GUI portions of Carbon are going out of
style. The lower level stuff like the File Manager seems to be
sticking around. (Well not the old FSSpec stuff but the modern FSRef
APIs.) Actually it seems like some things are being moved from Carbon
-> CoreServices to make the distinction.
A good way to evaluate the chances of a technology to remain viable
is its support in 64 bit applications. Apple is using that transition
to phase out lots of older stuff that has been superceeded by more
modern APIs. The File Manger and the Resource Manger are generally
available to 64 bit apps. See: <http://developer.apple.com/
documentation/Carbon/Conceptual/Carbon64BitGuide>
Anyway I remember reading somewhere that Apple warned about relying
on ..namedfork/rsrc always working. I can't find the reference at the
moment though.
There are other reasons to favor the File Manager over path based
APIs. One would be more robust behaviour in the face of moving files
and folders. Another would be avoidance of PATH_MAX problems.
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@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