Re: NSFileManager and aliases
Re: NSFileManager and aliases
- Subject: Re: NSFileManager and aliases
- From: Charles Srstka <email@hidden>
- Date: Mon, 15 Apr 2002 18:10:56 -0500
On Monday, April 15, 2002, at 05:15 PM, Erik M. Buck wrote:
Hopefully without starting a holy war:
As long as we stick to the issue and don't resort to personal attacks or
flames, we should be fine. So far, I think we're OK...
Aliases are nice. Symlinks are nice. they have different strengths and
weaknesses.
Hear, hear! I use both types of shortcut - symlinks for UNIX stuff that
I'll be using the Terminal for and aliases for Mac stuff that I access
via the GUI.
- Aliases do not work across volumes but symlinks do.
This is not true. I've had aliases pointing to things on other volumes
for years. It's pretty nice, actually - you can have an alias to
something on a removable disk that's not inserted, and when you
double-click on the alias, it will prompt you to insert the disk, and
soon as you do so, it will open the file. Or at least this is the way it
used to work in OS 9 - the functionality, like a lot of other things,
seems to be broken in OS X. Hopefully that will change...
- Symlinks are easy to break by moving the file that is the target of
the
link, aliases do not break so easily.
This is true.
- Symlinks work well in network environments with multiple network
volumes.
For example, a sys-admin can install an update of an application and
every
user's symlinks automatically point to the update. With aliases, this
is not
so easy. The admin may have to log into every users machine to update
aliases and the admin may not even know all the aliases that users have
created.
If you delete the original, shouldn't all the aliases point to the new
app if it is placed at the path where the old app used to reside? I
don't understand the problem here...
- Aliases work well on a local machine with one hard disk. They let
users
configure their machine the way they want it without fear of breaking
things. This was the traditional Mac configuration. Aliases are a
power to
the users feature. In the modern networked world, aliases are a new
ring of
hell for administrators.
No, one of the strengths of aliases (as fully implemented in OS 9 as
opposed to the half-baked implementation that currently exists in OS X,
hopefully to be fixed in future versions), was seen when you used them
with configurations where you had *more* than one drive. For example, as
I have mentioned before, you can make aliases of files on removable
disks that are not inserted, and it will ask for you to insert the disk.
Now when you throw networking into the mix, it gets really nice -
whenever I ever saw people using Classic that had an AppleShare server
they connected to often, how did they always do it? They usually had an
alias to the server in their Apple menu, and they mounted it simply by
hitting the alias. It automatically connected to the server, mounted it,
and opened it. It was very slick, and saved the extra step of having to
go to the Chooser/Network Browser/Go To Server and type the address of
the server. This is stuff that seriously needs to be put back into OS
X...
There are many traditional Mac features that worked best before
computers
were commonly networked.
There are many Unix features that do not work well if a computer is not
networked.
There are many traditional Mac features that give power to USERS to
configure THEIR machine the way THEY want it.
There are many traditional Unix features that give power to ADMINS to
configure the COMPANY'S machine the way the COMPANY wants it.
No, I would say that there are traditional Mac features *and* UNIX
features, both of which had their own purposes, and both of which worked
*just fine* regardless of whether a machine was networked or not. They
can coexist, and should.
This is a clash of cultures.
However, the days of non-networked machines are ending...
I agree that there is a clash of cultures. And it is unnecessary.
There's no reason we have to have any hostility at all towards each
other. If anything, we should be joining forces - if we both kept
sending feedback and got Apple to put back in all the missing features
from both Classic *and* NeXTSTeP that have disappeared in the
transition, we would have a truly great OS, much better than either of
its predecessors.
Charles
----- Original Message -----
From: "Charles Srstka" <email@hidden>
To: "Ondra Cada" <email@hidden>
Cc: "Robert Fischer" <email@hidden>; "cocoa-dev"
<email@hidden>
Sent: Monday, April 15, 2002 3:47 PM
Subject: Re: NSFileManager and aliases
I don't get it. Why do you hate aliases so much? They offer some nice
features and flexibility that symlinks do not. The only real drawback
is
that some API's haven't been updated to support them yet...
On Monday, April 15, 2002, at 03:16 AM, Ondra Cada wrote:
On Monday, April 15, 2002, at 09:40 , Robert Fischer wrote:
is it possible that NSFileManager does'nt know anything about alias
files?
Of course it is. Whole Cocoa, being unix-born and not MacOS-born, uses
the *standard* API, whilst aliases are very proprietary stuff of HFS+.
Use symbolic links instead (they work much more reasonably anyway).
Since Apple (triple alas!) pushes aliases to be used instead of
symlinks, it is extremely probable that all Cocoa classes will be made
alias-aware sooner or later. It will take some time though.
---
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
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.