Re: NSFileManager and aliases
Re: NSFileManager and aliases
- Subject: Re: NSFileManager and aliases
- From: Charles Srstka <email@hidden>
- Date: Tue, 16 Apr 2002 17:31:13 -0500
Sorry for the length of this reply - I figured that one really long
message would be better than a thousand short messages cluttering up the
list.
On Tuesday, April 16, 2002, at 01:28 AM, Ondra Cada wrote:
On Tuesday, April 16, 2002, at 12:49 , Charles Srstka wrote:
When you delete the old app, its file system entry no longer exists,
so it looks up the path, finds the new app, and launches it.
Wrong. It launches the old app from Trash.
Well, I said "deleted," meaning that you had emptied the Trash. But in
OS 9, this would have worked the way you want it to, without your having
to empty the trash.
In fact, I believe that unless the Dock is not following the rules
properly, an alias usually checks the path *first* and uses the file
system entry as a fallback if the file at the path location doesn't
exist,
causing things not to break as easily.
I should have added also
- the alias behaviour is so cryptic that even those who understand and
love them can't predict their real behaviour.
It's not the first time this happened ;)))
Hey, no flames. We're all friends here, remember? :-) I can tell you
exactly how they will behave *in OS 9*. Their behavior seems to be
somewhat broken in OS X.
Actually, so far as I understand, it's (generally? there can, actually,
due to the Jim Correia's posts, *must*, be special cases to mist it
even more!) exactly the opposite: an alias normally first checks the
"file system entry" (I think the proper name is a "file ref", though I
don't know quite well what it should mean), and only if it can't
resolve, it tries the path. Also it updates the path implicitly using
not-quite-intuitive rules, even if the file is just opened not changed,
which then self-evidently would bring more fuzziness if two otherwise
exactly same aliases lay in two portions of disk, one writable, one
without access rights... oh, spare me of the thing :((((((((((
Well, I speak from experience, having used aliases since they were first
introduced, and I can tell you that *definitely, without a doubt*, that
in OS 9 they check the *path first.* This seems to be broken in OS X,
but I just tested it with my hacked version of the OS 9 Finder running
in the Classic environment, and as of Mac OS 9.2.2, it works fine. If
the alias resides in a different folder than the original item, it goes
by the path, and uses the ID if the path doesn't exist. I can swap the
names of the two folders, and it changes to the folder that now has the
name its old target had. This doesn't work right in OS X, but one
interesting thing is that if I *create* the alias with the OS 9 Finder,
then the OS X Finder appears to use the OS 9 behavior when following it.
This leads me to believe that the OS 9 Finder (or perhaps the Carbon
alias-creating mechanism) is doing something wrong when *creating* the
alias. And as we all know, no one has ever found any problems with the
OS X Finder before... ;-)
Since you have a copy of OS X, you probably have an OS 9 CD around. If
you don't have the Classic environment installed, you can just boot off
of the CD without having to install anything, and test this for yourself
when booted from a CD. This is a feature of aliases that has been broken
in OS X, just like prompting to insert a removable disk. You can
complain about it all you want, but then I get to tell you how much the
NeXT shelf sucks based on using the Finder toolbar in OS X. ;-)
Similarly, I could complain about the NeXTStep API based on any of the
parts of Cocoa you say are broken... well, you get the point. It would
be more constructive for us both to send feedback to Apple asking them
to make aliases behave more like OS 9 (and fix the other stuff as well!)
though.
There's a way -- and so far as I can say, only way -- to do that:
integrate aliases on the filesystem level, so that all the low-level
calls (like fopen, open, etc.) are alias-aware the very same way they
are link-aware now. Also, aliases would have to stop using resource
forks, since that alone (not speaking of other things) makes them
unuseable: they can't be archived, copied, etc., since all standard
tools (like gnutar, cp,
ftp, telnet, whatever...) know just the standard file. If metadata is
really needed, a file package should be used instead: any standard tool
can cope easily with a folder.
Agreed. It would be nice to have them implemented at the file system
level. This can't be done immediately, though, as it would break
backwards-compatibility with OS 9. Once OS 9 is further back in the
distant past, I wouldn't be surprised if they do this.
If this was solved, I guess *PERHAPS* they might bring some advantages,
though I am not sure. Alas it seems Apple does not want to go this way,
and thus aliases are, well, just a perpetual grief.
What makes you so sure Apple will never do this? Didn't they just hire a
guy famous for writing the Be file system? They're probably planning a
new FS of some sort for the future...
Which is naturally an exact opposite of what I wanted. The very reason
I've used Trash instead of rm -rf was since I wanted to be able to
return back to the old app in case the new release is not quite good.
What you need is the OS 9 alias functionality, not the broken OS X
functionality.
As an example just compare the easy, intuitive, and
not-clashing-with-anything NeXTStep way of making folder icons (if you
dunno, folder just contained .dir.tiff and optionally .opendir.tiff for
a different image when the folder is open, and that was all) with the
OSX ugliness of non-sriptable, non-archivable, more or less non-useable
Icon file -- even without the .opendir functionality :(((
Hmm, I'm agreeing with you 100% on this. NeXTStep had the ability to
have a different icon when the folder was open? So did Classic Mac OS,
so why doesn't OS X have this?! I always kinda figured it was a NeXT
thing to have the same icon in both cases, and that someone decided to
go with that instead of the Mac way... what the hell?
On Tuesday, April 16, 2002, at 03:29 AM, Thomas Lachand-Robert wrote:
Now a suggestion (fell free to comment, eventually we could file a
feature request on this):
I think a useful improvement to aliases would be to have them
recognized as symbolic links by the Unix tools. If I understand well
the machinery, it should not be very difficult:
-- Aliases doesn't need to have data fork (I don't know if they have,
but usually they don't, they appear as 0-sized files in the terminal.
-- Symbolic links doesn't have any resource fork, but the path is coded
somewhere in their data fork.
So a simple solution would be to have all aliases copying the path they
already store inside their data fork, in addition to their resource
fork.
That's a really clever idea. I wonder why no one has ever thought of
that before? The bad news is that it would make alias behavior very
inconsistent - it would behave differently depending on whether you used
the Finder or the Terminal to access them...
On Tuesday, April 16, 2002, at 03:52 AM, Ondra Cada wrote:
...this was true, which it is *NOT*, I would not complain a bit: I
would just set the global default "NSUseSymLinksAlways", and be happy
(but for support, but that's another story).
Support? Most of the problems you are citing aren't going to be run into
by new users nearly as often as the problem of moving a file and
breaking a symlink. You can't expect new users to understand paths, and
if they don't, it will make *absolutely no sense* why something as
simple as moving a file breaks the alias pointing to it.
At the first look this seems nice. Add a system-wide switch "use path
primarily" or "use fsref primarily", and I guess we would be quite
close to a really good solution.
From the symlink POV it looks really nice (of course, unless I am
overlooking something obvious ;)). Anyone who understand aliases well
wants to comment on from that POV?
No problems that I can think of, except that it requires users to
understand this stuff, which usually works invisibly in the background.
Better would just be to make "use path primarily, but use the fsref when
needed" the default behavior, as in OS 9, and then I think everyone's
problems would be solved. But this solution is definitely better than
what exists right now...
Charles
_______________________________________________
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.