Re: Philosophy of FSRef - way
Re: Philosophy of FSRef - way
- Subject: Re: Philosophy of FSRef - way
- From: Shawn Erickson <email@hidden>
- Date: Fri, 11 Feb 2005 11:08:27 -0800
On Feb 11, 2005, at 10:34 AM, Ed Baskerville wrote:
On Feb 11, 2005, at 1:19 PM, mark wrote:
I don't think the accepted convention was to store FSRefs--if you're
going
to store references, you should be storing aliases, NOT FSRefs.
Depending
on OS version (10.2+?), I believe that aliases now resolve path name
first
(so your example would be covered).
Cool. Thanks for the info--I guess the last I heard about this was
somewhat before Jaguar.
So, for the example I gave, you should be using aliases (not FSRefs)
regardless of if the app was quit and reopened, because the behavior
should be the same whether it's done while the app is running or not,
no?
Hard to answer without knowing the exact behavior you want but as I
understand things...
While your application is running...
1) If you want to always use the current file with a given name path
then use an FSRef but create it on demand to insure you get the current
file that lives at the location you want.
2) If you want to always use the same file even if it may have moved on
you use FSRef and don't recreate it (can validate it as needed however
if you want).
3) Get an alias to the file and resolve the alias when needed (likely
to an FSRef) but this is likely over kill given 1 & 2.
Also note I believe as long as you have a file open you get that file
even if it has been moved or even deleted since it was opened (at least
via BSD APIs...).
While your application is not running...
1) If the files you want to worry about are supposed to be at a fixed
location/name and that is all you ever want then store paths.
2) If you want to track files then store aliases.
For more information on alias semantics in Mac OS X...
<http://developer.apple.com/documentation/MacOSX/Conceptual/
BPFileSystem/Concepts/Aliases.html.
-Shawn
_______________________________________________
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