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: tonza on Dec 16, '02 08:21:23PM

... aliases are HFS-specific constructs which allow the Mac OS File Manager to track locations of other files based on volume ID and file ID. If you make an alias, and move the original around, the Alias Manager will use the following technique to find its corresponding original:

- it looks for the original file by its ID.
- if the file of that ID does not exist, or it is not of the same type and
creator (another reason why filename suffixes suck!), it looks for the file
by its pathname at the time the alias was created.
- if a file of that path does not exist, or a file of that path has a
different type or creator, the Alias Manager declares that alias as
unresolvable.

Symbolic links only assist if the original never moves. Once the original file moves, its symbolic link is broken. However, symbolic links work across mounted filesystems.

Another mechanism that is useful is a hard link. Hard links point to the same inode (file ID on HFS filesystems), so if an original file moves around, its hard link would not be broken because it is one and the same file reference.

Aliases are constructs that adopt the linking techniques of both one-volume symbolic and hard links. The only issue is that BSD (UNIX) tools don't know what aliases are, since the kernel does not know about aliase files on HFS filesystems. Maybe the filesystem drivers in future Mac OS X revisions will make aliases appear as self-revising symbolic links. Currently, only the Alias Manager in the Mac OS X application APIs knows about aliases.



[ Reply to This | # ]
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 | # ]