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


Click here to return to the 'Alias vs. symbolic link' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Alias vs. symbolic link
Authored by: incongruity on Dec 16, '02 11:53:44AM

So, why then aren't aliases simply implimented using symbolic links? It would seem to me to make much more sense as far as getting the GUI and CLI to work well together. What are the advantages of the current implimentation of aliases, other than legacy OS9 compatibility?



[ Reply to This | # ]
Alias vs. symbolic link
Authored by: bussdriver on Dec 16, '02 01:38:16PM

Aliases do not quite work the same in X as they did in Classic; however there are a few reasons they are still around:

a)
Backward support for 9

b)
Users are familar with the term alias; a link is web terminology.

c)
symbolic links seem to be a lot like aliases...hard links are not...fooling around with it-- it sure seems the same...Ah! It does not work with servers! Its still somehow either path based or node based or something.


Aliases as in Classic (and it seems mostly in X) store a reference to the file on the drive. If I remember right, they have 3 flavors too... Anyway, they can also store path information but the idea is they link to the item ITSELF.
This means you can make an alias and move the source item around the drive and it still works. (try that with window's shortcuts!)
Don't remember the info about it, its possible they are more powerful; since they were created after unix links were invented. I bet that 3rd method involves servers...



[ Reply to This | # ]
Hard links
Authored by: thinkyhead on Dec 16, '02 04:50:08PM

... are quite unique. They are additional directory entries for a given file or folder. The file itself maintains a reference count indicating how many directory entries are allocated to it. If you delete the original file and you have a hard link to that file then the file is not in fact deleted, but only the directory entry for the file, and the reference count is decremented. The hard link then becomes the primary directory entry for the file. Only when all hard links are deleted - and the reference count goes to 0 - will the file actually go away.

Hard links can sometimes cause complications for backup software, because they treat each hard link as another copy of the same file. I think Retrospect has this problem, perhaps because there are any system level APIs to distinguish between a real file and a hard link. OTOH such APIs may have been incorporated at some point.



[ Reply to This | # ]