• 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: Philosophy of FSRef - way
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Philosophy of FSRef - way

  • Subject: Re: Philosophy of FSRef - way
  • From: "M. Uli Kusterer" <email@hidden>
  • Date: Sat, 12 Feb 2005 00:23:04 +0100
At 12:55 Uhr -0500 11.02.2005, Ed Baskerville wrote:
Say you're using an app that has the notion of a "project" that contains references to other files. It stores both pathnames and FSRefs to these files.

If it stores FSRefs, it's screwed. Neither FSRefs nor FSSpecs are guaranteed to be valid across launches of your app. With FSSpecs you could sometimes get away with it, but only as long as the order of drives on your computer didn't change (then the volume refNum would change, and your references would be useless).

And your expectation of how project files would work comes from the fact that you're used to paths, and you expect C to use paths for locating headers. That's how GCC expects it, too, and since Apple didn't want to completely rewrite GCC, they didn't change that. Usually, when actual end-users move a file to another folder, they don't expect it to lose its connection. It's still the same file.

I guess when you use an xCode project, you expect the folder containing the project to be special. In that case, xCode should work by scanning the current folder, and, like iTunes with its library, it should reorganize the directory as is suitable. It's just a case of metaphor and, at least in my opinion, xCode doesn't really have a clean metaphor. But that's okay, because programmers expect it to work that way since they're used to it.

But as I said in my previous message, Cocoa does most of this right already (I think the "recent files" list still occasionally lost track of moved or renamed files, but that's it) if you're using NSDocument, so no need to mess with this unless you plan to go low level.

And I think that's it from me on this topic. This is really getting farther and farther away from being Cocoa-related.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
  • Follow-Ups:
    • Re: Philosophy of FSRef - way
      • From: Jason Jobe <email@hidden>
References: 
 >Re: Philosophy of FSRef - way (From: Ruslan Zasukhin <email@hidden>)
 >Re: Philosophy of FSRef - way (From: "M. Uli Kusterer" <email@hidden>)
 >Re: Philosophy of FSRef - way (From: Jim Hagen <email@hidden>)
 >Re: Philosophy of FSRef - way (From: Brendan Younger <email@hidden>)
 >Re: Philosophy of FSRef - way (From: Ed Baskerville <email@hidden>)

  • Prev by Date: Re: Binding Array of NSNumbers
  • Next by Date: Re: Philosophy of FSRef - way
  • Previous by thread: Re: Philosophy of FSRef - way
  • Next by thread: Re: Philosophy of FSRef - way
  • Index(es):
    • Date
    • Thread