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

Use symbolic links instead of aliases on the desktop Desktop
If you make aliases on your Desktop of folders like "Home" and "Applications," you'll notice that they all have the same generic folder icon. While this hint does not cover how to set your own icon, you can use the icon the folder provides by using UNIX's symbolic links. First delete any aliases from your Desktop that have a pretty icon in the Finder. Then use the Terminal to create a real symlink:
 % ln -s /Applications ~/Desktop/Applications
% ln -s ~/ ~/Desktop/Home
Then click on your Desktop and you'll have a pretty "Application" and "Home" icon.

[Editor's note: The other big advantage of symbolic links over aliases is found when you use the Terminal. If you try "cd ~/Desktop/Applications" it will fail if you created an alias in the Finder, but it will work perfectly if you created a symbolic link instead. I'm not sure if this is a bug or feature or if my machine is just messed up, but I first noticed it with a Downloads folder that I keep on another drive. I had created an alias on the desktop, then tried to 'cd' into the alias to compile a UNIX app I downloaded. Once I changed it to a symlink, everything was fine.]
    •    
  • Currently 3.20 / 5
  You rated: 4 / 5 (5 votes cast)
 
[17,926 views]  

Use symbolic links instead of aliases on the desktop | 20 comments | Create New Account
Click here to return to the 'Use symbolic links instead of aliases on the desktop' 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 | # ]
yes but...
Authored by: zedwards on Dec 16, '02 02:37:29PM

OS X is Unix, therefor, symbolic links are how you make what people in the mac world call aliases. Although this may be legacy to os 9, it is probaby not how is should work and you would get in trouble if you were running a server of unix apps and were using aliases. This is what happens when the gui and cli collides.



[ Reply to This | # ]
Exactly
Authored by: Xeo on Dec 16, '02 04:42:45PM

Symlinks are like Windows shortcuts. They are path based, relative or hard references. This can be fine for most things, but they simply don't work as well as aliases. However, the CLI doesn't know what an alias is so it collides a lot. Aliases are a lot better from the GUI side of things.

Apple needs to make a new type of alias which the CLI can recognize as if it were a symlink, but one that would act like an aliase, even in the CLI.



[ Reply to This | # ]
Links aware GUI
Authored by: skalpa on Dec 17, '02 07:47:06AM

Actually, I don't think making the CLI recognize aliases is possible. However, the opposite can be done easily: the GUI could be enhanced so it's able to handle / create 2 types of 'aliases': legacy ones (a-la-MacOS) and unix ones (symlinks). 10.3 feature ??



[ Reply to This | # ]
Links aware GUI
Authored by: Krioni on Dec 17, '02 04:09:49PM

Um, the GUI already "handles" sym-links, at least. I don't think you can create them in the Finder, but you can certainly follow them. It would be nice to add the ability to create them in the Finder, as well, and certainly wouldn't be hard. The OnMyCommand contextual menu plugin allows you to write comand-line programs that act on the selected file, so it would be easy to add a "Create Symbolic Link" command in about 1 minute worth of writing. Check out VersionTracker if you want to try OnMyCommand - it's free, and I love it.



[ Reply to This | # ]
Desktop Trash
Authored by: theharvestman on Dec 16, '02 07:48:15PM

I dont suppose there is any way this can be adapted to put a trashcan on the desktop?



[ Reply to This | # ]
Desktop Trash
Authored by: wealthychef on Dec 17, '02 08:27:15PM

Well, sort of. I tried the following in the Terminal:
ln -s ~/.Trash ~/Desktop/Trash
and I ended up with a folder called "Trash" on my desktop. Good enough? You tell me.



[ Reply to This | # ]
Desktop Trash
Authored by: christefano on Dec 05, '05 04:12:58PM

There's also SideTrash, a freeware utility (AppleScript-based, I think) that you can put in the sidebar of the Finder's windows. There's no reason you couldn't rename it "Trash" and put it on the desktop, as well.

http://macupdate.com/info.php/id/17686

Unfortunately, because it's an application SideTrash will have a ".app" file extension (if you have "show all file extensions" turned on in the Finder), revealing that this is something of a juryrigged workaround.



[ Reply to This | # ]
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 | # ]
GUI / CLI
Authored by: sukie on Dec 17, '02 06:51:09AM

I think the real stumbling block is that the Aqua GUI is not a GUI *of* the CLI as it is with any other UNIX based system such as linux or HP-UX. Aqua uses the UNIX kernel. Darwin shells use the UNIX Kernel. They're not very good at talking to each other. Some apps made in aqua are simply a graphical representation of familiar unix commands, but the finder for example (although greatly improved in 10.2) seems to ignore changes on the command line such as permissions and owners of files.

Hence the issue of symlinks and aliases causes problems for anyone who uses both sides of the OS.



[ Reply to This | # ]
Aliases...
Authored by: Elektron on Dec 19, '02 06:57:07AM

... are just normal files with the "alias" flag set and an "alis" resource.

There is nothing fundamentally special about alias files, except the alias flag set. You can even store data in them, just that most apps choose to follow the alias instead of accessing the alias itself.

Symlinks, on the other hand, are special files. You can't read and write data to them. They just store a path.


The default MacOS calls access the file itself. You must "decide" to follow aliases.
The default UNIX calls access the file pointed to. You must "decide" to access the symlink (and accessing symlinks like they were normal files would just produce errors anyways).

Most (carbon) programs decide to follow aliases (symlinks) to make it easy for the user; e.g. putting my Chimera cache on another partition. I don't know how cocoa programs usually work.


To be accurate, symlinks on an HFS+ system are just type "slnk" creator "rhap" files (with the alias flag set), with the path stored in the data fork.

But to follow aliases on a command line would require the kernel to interpret the "alis" data and stuff. And then the path would change with the target.



[ Reply to This | # ]
Palm and iCal aliases
Authored by: EricW on Jan 10, '03 06:09:44AM

I've used aliasing in OS X to 'trick' apps that demand a directory in specific locations to believe they're there while in fact I have them on another drive that's mirrored home and office via a firewire pocket drive.
Tried this with iCal and Address book but its not a hapening thing and am wondering if symbolic linking might be the answer.
Any ideas



[ Reply to This | # ]
Keep both!
Authored by: R1 on Dec 20, '02 03:53:35AM

Interesting and accurate things have been said. It's important to add that neither symlink nor alias is better than the other. They actually both match their respective environments -CLI and GUI- in terms of flexibility.

Turn aliases into symlinks to make admins happy, and many users (we work for them, remember) won't find their needles in the hay anymore. Do the contrary and the system may behave strangely, finding things he's not supposed to be smart enough to find.

Symlinks' sin and virtue is that they don't follow an original when you move it. That means they're perfect for things that you don't rummage around with (inside the system, eg). Aliases' sin an virtue is that they do follow originals, which suits most end users.

As for hard links, I would strongly advise against them for anyone who doesn't stick to CLI. My Finder growls every time he sees one, it can't really decide what it is. Forget hard links in the Finder, you'll feel better...

One of the -already mentioned- ways of making everyone happy would be to update the system so that it resolves aliases as if they were symlinks. But I would reeealy think twice about possible consequences if I was in charge of the project.



[ Reply to This | # ]
re:
Authored by: apetersen on Jul 11, '03 04:15:23PM

Hey people.

Im having some problems which i hope i can get some help with.
Here is the issue. I run a couple of windows 2000 servers. On 1 of these servers i made a symbolic link to 1 of the other server, this workes fine with all the pc user machines, but all the mac's just see this link as a empty folder. I checked if it matters if it's OS X or later... It doesn't :(
Any 1 have any bright ideas to what to do...?
Neeed help



[ Reply to This | # ]
Use symbolic links instead of aliases on the desktop
Authored by: apetersen on Jul 11, '03 04:18:56PM

Hey people.

Im having some problems which i hope i can get some help with.
Here is the issue. I run a couple of windows 2000 servers. On 1 of these servers i made a symbolic link to 1 of the other server, this workes fine with all the pc user machines, but all the mac's just see this link as a empty folder. I checked if it matters if it's OS X or later... It doesn't :(
Any 1 have any bright ideas to what to do...?
Neeed help



[ Reply to This | # ]