Re: Philosophy of FSRef - way
Re: Philosophy of FSRef - way
- Subject: Re: Philosophy of FSRef - way
- From: mark <email@hidden>
- Date: Fri, 11 Feb 2005 10:19:41 -0800
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).
Alias are almost always better than just path names, as if the path name
fails, they can attempt to find the file if it has been moved or renamed.
Aliases also can be relative--i.e., a file relative to your app bundle. I
would say you would only NOT want to use aliases if there's some reason you
don't want to load files that have been moved or renamed (maybe particular
data files?).
Mark
> From: Ed Baskerville <email@hidden>
> Date: Fri, 11 Feb 2005 12:55:12 -0500
> To: Brendan Younger <email@hidden>
> Cc: cocoa-dev Dev <email@hidden>
> Subject: Re: Philosophy of FSRef - way
>
> On Feb 11, 2005, at 12:05 PM, Brendan Younger wrote:
>
>> That's backwards. Don't think of FSSpec's as being "higher level";
>> they aren't. FSRef's are *always* the way to go if the file already
>> exists. If the file doesn't exist, then you can take your pick from
>> paths, FSSpec's, Aliases, etc. to refer to it.
>
> In the traditional Mac OS world, this was the accepted convention. I'm
> not sure what the accepted convention is now, nor have I come to a firm
> conclusion myself, but I've heard the opposite case made fairly
> convincingly along these lines:
>
> 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. The user has previously made a backup of one of these
> files in a different location, and, after making some changes to the
> file, decides to revert to the backup. They* move the file out of its
> current location, and move the backup to where it just was, so that the
> project begins using the backup rather than the file with the unwanted
> modifications.
>
> If you lean on FSRefs as your primary method of referring to files, the
> app will do exactly the opposite of what the user wanted: it will
> continue to use the file that was just moved, rather than the backup
> that was put in its place. If the user understands FSRefs, they won't
> be surprised by this--but can we expect users to understand FSRefs?
>
> Note that Xcode, certainly, uses POSIX paths as its only way of
> referring to files. (And Xcode users are far more likely to understand
> FSRefs than, say, Flash users--but, as discussion on this list makes
> evident, it can't be assumed even there.) It would perhaps be nice if
> it could lean on FSRefs as a backup, but if you move a file and replace
> it with another file of the same name in the same location, chances are
> you want it to use the *new* file, not the old one.
>
> But I may yet be convinced of the superiority of the FSRef-first
> approach. :)
>
> --Ed
>
> * fast becoming an accepted gender-nonspecific singular pronoun
>
>>
>>> Ruslan, if you're interested in the equivalent Cocoa functionality,
>>> it's easy to find :
>>>
>>> file:///Developer/ADC Reference Library/documentation/Cocoa/
>>> FileManagement-date.html#//apple_ref/doc/uid/TP30000416-TP30000448
>>>
>>> and the relevant Carbon docs, which I didn't see anyone point you to :
>>>
>>> file:///Developer/ADC Reference Library/documentation/Carbon/
>>> FileManagement-date.html#//apple_ref/doc/uid/TP30000420-TP30000448
>>>
>>> The "File Manager Reference" contains many important bits of info,
>>> like "You should not access File Manager structures directly if
>>> accessor functions for the structure exist."
>>>
>>> On Feb 10, 2005, at 12:11 PM, M. Uli Kusterer wrote:
>>>> Well, I don't have to worry about FSRefs. NSDocument uses them
>>>> internally anyway.
>>>> --
>>>
>>> Wouldn't NSDocument use NSFileHandle ?
>>
>> No, because NSFileHandle requires the file to be open for either
>> reading or writing. There's no particular reason for NSDocument to
>> keep the file open all the time. FSRef's provide a way to track the
>> file even when not open.
>>
>>> Of course, I suppose NSFileHandle could lean on FSRef and FSSpec,
>>> though I don't know it should need to. I've seen Carbon apps pass the
>>> mangled name[31] to other parts of the system, like for printing, and
>>> I can imagine using FSRef directly too much can lead to similar
>>> problems. Programming in Cocoa, we're pretty insulated from this kind
>>> of stuff. NSData and NSDocument do the heavy lifting for us,
>>> generally. I likewise can't think of the last time I used even
>>> NSFileHandle directly.
>>
>> Just to clarify: you can *never* go wrong with an FSRef. The name
>> mangling that FSSpec's are prone to doesn't exist with FSRef's.
>> Please don't think for a moment that paths or URLs (i.e. the Cocoa
>> way) is to be preferred for any reason other than convenience.
>>
>> Brendan Younger
>>
>> _______________________________________________
>> 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
>>
>
> _______________________________________________
> 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
_______________________________________________
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