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: vonleigh on Dec 16, '02 11:45:32PM

Actually, from my tests under OS X, it first checks for the path, if it cannot find the original file at the specified path then it looks for the file using it's ID.

I posted this already as another comment, but here's how you can test it (it gets confusing but just try it out):

1. Create a folder, call it "TestFolder". Create a file inside this folder called "mystuff" (use touch or TextEdit).

2. Create an alias to this folder, by default it will be called "TestFolder alias".

3. Now do this, move your "TestFolder" to a different location on your HD. Then create a new "TestFolder" (same name) in the location where the previous one used to be.

4. Open your alias. Note that it's opening your new "TestFolder" as this one is empty and does not contain "mystuff".

5. Delete the new "TestFolder". Open alias, note how it finds your original "TestFolder" correctly, as this one does contain "mystuff".


So from this I'm concluding that first the path is checked, and if a file with the same name in the same location is found, it is assumed that is the alias. But if it is not found where it's supposed to be, then it'll look up the file but it's ID.


v



[ Reply to This | # ]
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 http://developer.apple.com/technotes/tn2002/tn2053.html 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 | # ]