• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: creating a resource fork and writing raw bytes to it
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 09:11:19 +0200

Am 22.05.2008 um 07:50 schrieb Charles Srstka:

On May 22, 2008, at 12:09 AM, Mike Fischer wrote:

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.

That was WWDC 2006, in which the speaker for one of the sessions commented that the /rsrc hack was going to be removed from Leopard. It didn't say anything about ..namedfork, though - just /rsrc, which I don't think anyone really uses anymore. Of course, /rsrc still works in Leopard, so who knows.

Here is the reference I was thinking of, but I was wrong: <http://lists.apple.com/archives/filesystem-dev/2008/Feb/msg00017.html>

Quinn <email@hidden> wrote on 02/20/2008 20:59:44 +0000:
[Talking about Tiger...]
Also, the kernel did not provide stream access to the resource fork.
You could get and set the resource fork via the extended attributes
API, but you could not open a file descriptor to the resource fork on
all file systems.  The "foo/..namedfork/rsrc" trick would work on
volumes that supported the resource fork natively, but would not work
on volumes that stored the resource fork in an AppleDouble file.

o In 10.5 we got rid of the File Manager's AppleDouble code.  File
Manager now (more-or-less) treats all volumes the same.  The
implementation of the native/AppleDouble abstraction layer is now
done entirely within the kernel.

This means that, when you access metadata via BSD APIs, you're
accessing through exactly the same API that File Manager uses.
Neat-o!  It also means that you can do the "..namedfork/rsrc" trick
on all volumes [1].  For example:


So the situation actually got better and it seems that ..namedfork/ rsrc is now supported on all volume formats. Sorry about the confusion.


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


References: 
 >Re: creating a resource fork and writing raw bytes to it (From: Mike Fischer <email@hidden>)
 >Re: creating a resource fork and writing raw bytes to it (From: Charles Srstka <email@hidden>)
 >Re: creating a resource fork and writing raw bytes to it (From: Mike Fischer <email@hidden>)
 >Re: creating a resource fork and writing raw bytes to it (From: Charles Srstka <email@hidden>)

  • Prev by Date: Re: ObjC Question - labeled arguments
  • Next by Date: Re: ANN: Step by step introduction to programming with Cocoa
  • Previous by thread: Re: File Manager and FSRefs [was: creating a resource fork and writing raw bytes to it]
  • Next by thread: NSSecureTextField and paste
  • Index(es):
    • Date
    • Thread