Re: Philosophy of FSRef - way
Re: Philosophy of FSRef - way
- Subject: Re: Philosophy of FSRef - way
- From: Jim Hagen <email@hidden>
- Date: Fri, 11 Feb 2005 15:40:36 -0800
Thanks for the clarification. Although I hadn't really meant "drop down
to the FSRef level" in quite the way it was taken, I was clearly
confused as to where the name-length-limit came in. My brief look at
FSSpec failed to catch that their use is clearly discouraged, probably
because
file:///Developer/ADC Reference Library/documentation/Carbon/
Reference/File_Manager/file_manager/data_type_40.html#//apple_ref/c/
tdef/FSSpec says nothing about that, and I didn't bother to look at the
deprecated functions page. Maybe the folks who write Word would be
interested in that... and should maybe that FSSpec page I just
referenced mention something about it's use being discouraged?
It's only been a decade or so since I've used these... I somewhat
regret posting on the topic, but the ensuing discussion shows I'm not
the only one in the dark here, so it has been educational, at least.
Using AliasHandle to keep track of a file across restarts is
interesting, but somehow I hope I never need that feature...
On Feb 11, 2005, at 3:10 PM, M. Uli Kusterer wrote:
At 8:48 Uhr -0800 11.02.2005, Jim Hagen wrote:
At 16:41 Uhr +0200 10.02.2005, Ruslan Zasukhin wrote:
1) It looks very weird that I cannot create Fsref for non-existing
object,
Like we was able do this with FSSpec. What a great idea is behind
of this?
Clearly this entire line of questioning is one for the Carbon list,
but it would seem from a quick glance at the functions and
documentation it looks like you're expected to use FSSpec until you
_need_ to drop down to the FSRef level. This makes sense when you
look at the FSRef structure and realize that it doesn't store the
full file path name.
No, that's definitely wrong. FSSpec is a holdover from the System 7
days and was replaced with FSRefs when HFS+ came around. Use of
FSSpecs is discouraged, because when you create a file using an
FSSpec, the file name's length is limited to 31 characters (the
original HFS limit) and you can only choose one of the traditional Mac
text encodings (or "script codes", as they were called back then).
These *don't* include Unicode.
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,
Yes, those are older apps that still use FSSpecs internally.
and I can imagine using FSRef directly too much can lead to similar
problems.
Actually, it can't. If you request the name of a file by FSRef, you
get an HFSUniStr255, which is Unicode and long enough to hold any file
name. Of course, for a print job you should be using the file's
display name anyway, which you can get from Cocoa (NSWorkspace or
NSFileManager, not sure right now), or from Launch Services.
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.
Yes. In most cases you won't need to go outside Cocoa to work with
files. And there's nothing wrong in using Cocoa's POSIX paths for
quick file access, like it's typically done in NSDocument. Just
holding on to a file for a little longer requires you to use other
means. If you intend to keep a reference to a file across restarts of
your app, you need to drop down to AliasHandles, but other than that,
it's really not needed.
--
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