• 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: Cocoa stripping resource forks: does Jaguar fix?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa stripping resource forks: does Jaguar fix?


  • Subject: Re: Cocoa stripping resource forks: does Jaguar fix?
  • From: Kirk Kerekes <email@hidden>
  • Date: Wed, 3 Jul 2002 09:20:27 -0500

On Tuesday, July 2, 2002, at 10:57 PM, email@hidden wrote:

On Tuesday, July 2, 2002, at 10:00 , Kirk Kerekes wrote:

We are not working on a BSD system here, even though one is buried
underneath. We are working on a HFS+ filesystem that explicitly supports
resource forks.

And that pretty much ends the discussion. When working inside this
filesystem...

Again, you are wrong.

BSD is a portable API. posix is portable API. The very same stands for
shell scripts. Cocoa should be a portable API, though Apple has messed up
OpenStep considerably.

Therefore, if a filesystem wants to work under it, *IT* has to support
what's needed -- not by dirty tricks like the special names, but by a way
which can be reconciled with the *STANDARD* techniques of BSD, posix,
shell scripts, OpenStep, whatever. If it does not, it's its fault -- in
this case, the blame is on the side of HFS+.

Cocoa/OpenStep is now a tool of the Mac experience, not a separate, discrete entity that happens to be residing on a Mac at the moment. This is one of the hardest lessons for the "step" folk to take. While the Mac community jokes that "NextStep acquired Apple", the reality of the marketplace is that OSX _must_ operate the way that Mac _USERS_ want, not the way that openStep purists would like.

If Cocoa "must" be a portable API, then it is COCOA's job to be capable of being used correctly on all target systems -- and that includes being responsible for correctly preserving user data, even if it is in a format that Cocoa does not understand.

How "portable" are file packages, anyway? How "portable" are ".rsrc" files?
How portable are colon-separated paths? Yet Cocoa supports them all, because they represent the _requirements_ of the Mac filesystem.

Supporting resource forks is no different -- just one of the _requirements_ of being a good Mac citizen.

And such support does not damage portability (a total straw-man issue). Forked files are a superset of flat files, so the ability to handle forked files does not affect the ability to handle flat files on systems which are limited to them.

And Apple's AppleSingle/AppleDouble techniques for flattening forked files are readily available, universally documented and well understood.
_______________________________________________
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.
  • Follow-Ups:
    • Re: Cocoa stripping resource forks: does Jaguar fix?
      • From: Ondra Cada <email@hidden>
  • Prev by Date: Re: Installing a new login item? - Code that works!
  • Next by Date: Re: NSEnumerator ordering ?
  • Previous by thread: Re: Cocoa stripping resource forks: does Jaguar fix?
  • Next by thread: Re: Cocoa stripping resource forks: does Jaguar fix?
  • Index(es):
    • Date
    • Thread