Re: Aliases & fileAttributesAtPath:
Re: Aliases & fileAttributesAtPath:
- Subject: Re: Aliases & fileAttributesAtPath:
- From: Ondra Cada <email@hidden>
- Date: Sun, 14 Oct 2001 12:19:07 +0100
Chris,
>
>>>>> Chris Hanson (CH) wrote at Sat, 13 Oct 2001 22:46:17 -0500:
CH> >They would, on the other hand, break almost anything what used to work
CH> >originally, from shell scripts through posix or BSD API tools to Cocoa
CH> >applications.
CH> >
CH> >Soft and hard links though work quite properly with all that.
CH>
CH> Cocoa doesn't default to resolving aliases in the middle of paths?
CH> That's bogus. Just points to more need to update Cocoa to handle
CH> FSRefs and AliasRecords. Of course, you should never actually be
CH> *storing* paths as persistent file references, so neither you nor
CH> your users should actually encounter such a situation in common use.
This is exactly the Mac OS 9- speak I am so angry with.
The file path is, always was, and always will be the primary means to
reference a file: it is intuitive, easy to use for both programmer and user,
and, which is the important thing:
***it is available with any API on earth***
There are not just Cocoa tools, not speaking of Carbon ones; there are posix
ones, bsd ones, ANSI-lib ones, perl/shell/python/anything scripts,
PostScript programs (yep, PS is a full-featured language which can work with
files, _OF COURSE_ using paths), and a gazillion of others I don't even knof
of.
OTOH, FSRef is a proprietary thing of Carbon and Classic, which does not
exist anywhere else. One day it might make it into Cocoa (I did not study the
new 10.1 NSDocument extensions religiously, but so far I understand it,
there is no FSRef either -- here I can be wrong though). Even if so, that
will make three, in a world full of APIs which almost all are portable,
UNLESS people like you win and make OSX as unuseable environment as Classic
always was.
Well, I do hope it never will happen. It would mean that we'll have to use
Linux or windoze, despite their shortcomings :((((
I could use FSRefs in my apps, of course, but I won't, and for good reasons:
there would be *MUCH* more other tools and applications which would behave
differently, and only a very small number of them -- those poor Classic
remnants -- which would behave the same way. You know, there is a whole world
outside your small Mac OS 9- niche, and OSX opened that world to you. Even
if I used the resolveAliasAtPath:, others won't -- since it is impossible.
There is not a way on earth to rewrite *ALL* those tools which now, thanks to
OSX, _CAN_ be used on Mac: find -L, all scripting environments, you name
it...
There is ONE AND ONLY ONE way how to support aliases so that they can be
really used in the plethora of tools and applications which are available: to
implement them in the filesystem level, so that they are just as transparent
from _PATH_ point of view as links are.
CH> PS - Here's an untested, never compiled method that will resolve an
CH> alias file at a particular path and return to you a new path...
CH> - (NSString *)resolveAliasAtPath:(NSString *)aliasFullPath
Yep, that is some workaround that can be used, temporarily, in Cocoa
applications and tools. I, for one, will use something similar in my new
apps, as an extra service used if a path cannot be accessed.
It won't solve the problem though; and even if Apple happens to put this
functionality into -[NSString stringByResolvingSymlinksInPath] where it
belongs to, it won't help: still there will be a plethora of Cocoa apps and
tools which won't use it, and infinitely much more non-Cocoa apps and tools
which will use plain paths for ever.
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
2K Development: email@hidden
http://www.2kdevelopment.cz
private email@hidden
http://www.ocs.cz/oc