Re: Aliases & fileAttributesAtPath:
Re: Aliases & fileAttributesAtPath:
- Subject: Re: Aliases & fileAttributesAtPath:
- From: Rainer Brockerhoff <email@hidden>
- Date: Sun, 14 Oct 2001 14:09:37 -0200
From: Ondra Cada <email@hidden>
Date: Sun, 14 Oct 2001 12:19:07 +0100
>>>>>> Chris Hanson (CH) wrote at Sat, 13 Oct 2001 22:46:17 -0500:
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.
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***
IMHO both aliases and links (and pathnames and FSRefs) are just tools
that are best for certain situations and not as useable for others.
Depending exclusively on file paths means one can never move files
around or copy/rename folders safely. Relying on absolute file paths
is what makes Windows so failure-prone. Using relative symlinks
restricts the vulnerability to the immediate hierarchy. The framework
versioning system uses relative symlinks so the framework can be
safely moved or copied, as long as one doesn't mess with the internal
structure.
Using file paths means that you should never have two volumes with
the same name. Now I agree that's in principle a good thing, but it's
sometimes unavoidable... I've run into situations where I had to
mount two CDROMs which had the same name, for instance.
Depending exclusively on aliases as Classic has always done is also a
bad thing, since there are many cases when one wants path constancy,
not file constancy... and aliases unfortunately have to be treated by
custom programming, which means many programmers never bother.
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).
Classic has _never_ had FSRefs. They have been introduced very
recently with the Carbon File Manager APIs, and aren't needed or used
for Classic applications.
FSRefs and aliases have been used in Cocoa from the beginning, and
certainly many of the NSFileManager calls use FSRefs internally,
since the underlying CarbonCore routines need FSRefs! The File->Open
Recent menu uses aliases, for instance, not file paths, and when you
open a document from there the alias gets converted to a FSRef. And
in 10.1 NSDocument uses FSRefs to track documents that have been
moved or renamed.
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.
For years I've submitted suggestions to Apple that aliases should be
followed transparently, but to no avail. On the other hand, following
aliases or links _always_ is also a bad thing. For my current XRay
utility, I've had to avoid nearly all Cocoa calls, and quite a lot of
CarbonCore or BSD calls, whenever I want to treat symbolic links
themselves as documents.
There are many downsides to the current blind following of links and
aliases. Dragging a symbolic link or alias on top of a Dock icon
_always_ resolves the path before the application gets it, without
any workaround. Clicking by mistake on an alias to an offline volume
(either in the Finder or in an Open panel means staring at the busy
cursor for minutes while the system tries to find the volume. This is
exasperating.
Ideally there should be an option in all calls to either follow
links/aliases or not, but that will never happen :-(
--
Rainer Brockerhoff <email@hidden>
Belo Horizonte, Brazil
"Originality is the art of concealing your sources."
http://www.brockerhoff.net/ (updated Oct. 2001)