Re: NSFileManager and aliases
Re: NSFileManager and aliases
- Subject: Re: NSFileManager and aliases
- From: Charles Srstka <email@hidden>
- Date: Mon, 15 Apr 2002 21:24:20 -0500
On Monday, April 15, 2002, at 08:23 PM, David Rehring wrote:
On 4/15/02 3:55 PM, Charles Srstka at email@hidden wrote:
On Monday, April 15, 2002, at 05:24 PM, Ondra Cada wrote:
On Tuesday, April 16, 2002, at 12:17 , Jim Correia wrote:
- aliases (just like hardlinks) can't be folder-relative
This is inaccurate. One can make a relative alias. There is no UI in
the Finder for doing so, but it *is* possible programatically.
I stand corrected, then. But, well, it kinda goes very strictly
against
what all those Carbon experts taught me:
Aliases don't reference path(*); they use a global file ID (something
like inode) instead: how they could be path-relative?
(*) Actually they do, but only as a backdrop for case the primary
means
of referencing does not work.
Hmm, it seems like the behavior has been changed in OS X, then. The
behavior in OS 9 was definitely to go by the path first, and use the
file ID if the file at that path did not exist.
I've always found that for OS 9, the primary behavior was to track the
'global file id' [I forget the proper term], and then if that wasn't
available, to go with the path.
That's the common opinion on the subject, but when I try it in OS 9, I
can rename a folder and give another folder the first folder's original
name, and the alias will change to point to the new folder, as long as
the alias and the folders are not in the same enclosing folder. Could
just be me, though...
In OS X, the ID seems to be given first priority in all cases that I
have tested.
_______________________________________________
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.