Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'symlinks != aliases because...' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
symlinks != aliases because...
Authored by: Krioni on Dec 17, '02 04:05:30PM

ACK!!! That is NOT how it used to work! When did this change? It used to be that aliases would follow the MOVED folder first, and then, only if it is totally gone, look at the original path.

This seems to fall in the "Well, there are two ways to do this, both with advantages and disadvantages. Nothing has really changed to tip the scales, but we feel like 'improving' things, so let's just toggle the behavior. That will only screw up the assumptions of millions of users." category. I've seen a bunch of things like this in OS X. I actually like most of the changes that have been made, but this one has the feel of being at best a neutral change, which is never worth destroying consistency over.

[ Reply to This | # ]
symlinks != aliases because...
Authored by: garbanzito on Dec 19, '02 01:40:36AM

i can confirm that it didn't used to work this way.. i did a careful test in 10.1.5 (i think -- it was july 2002) showing the file reference was tried first, and if that failed the path was used.. i also noted some bugs in the implementation

i have just checked the Jaguar technote at and noted the change was documented: "Alias resolution now begins with attempting to resolve the file path name first before attempting to resolve the alias using the file id. This is a fundamental change in the way aliases are resolved and it corrects a problem that would prevent aliases from working as expected on volumes restored from a back up copy. New flags have been added to specify the previous behavior (where the file id would be tried first). Pass kARMTryFileIDFirst to calls which accept a rulesMask or kResolveAliasTryFileIDFirst to calls which accept mountFlags to specify the file id first behavior. (r. 2683228)."

so unfortunately in addressing one problem (perhaps spurred by Dantz & Retrospect, though Retrospect didn't have this problem in Mac OS 9) Apple has created many potential other problems

[ Reply to This | # ]