Macworld Forums

Macworld Forums: Aliases vs. Symbolic Links - Macworld Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Aliases vs. Symbolic Links

#1 User is offline   persistentcookie 

  • Member
  • PipPip
  • Group: Members
  • Posts: 28
  • Joined: 28-February 11

Posted 04 January 2012 - 04:50 AM

Can someone explain the difference between creating an alias to a folder vs. a symbolic link? Is there an advantage to one or the other? Most websites suggest the creation of symbolic links when using Dropbox, specifically. If symbolic links are better, can someone explain the procedure to me? I have a feeling I'm doing it backwards...Thanks

This post has been edited by persistentcookie: 04 January 2012 - 04:51 AM

0

#2 User is offline   Typhoon14 

  • Veteran
  • PipPipPip
  • Group: Members
  • Posts: 2,966
  • Joined: 02-February 01

Posted 04 January 2012 - 02:58 PM

View Postpersistentcookie, on 04 January 2012 - 04:50 AM, said:

Can someone explain the difference between creating an alias to a folder vs. a symbolic link? Is there an advantage to one or the other? Most websites suggest the creation of symbolic links when using Dropbox, specifically. If symbolic links are better, can someone explain the procedure to me? I have a feeling I'm doing it backwards...Thanks


In a nutshell, aliases point to a file or folder, regardless of its location on the disk. If you move it, the alias will continue to point to it at its new location.
In contrast, symbolic links point to a path. For instance, I might have symbolic link that points to "/Users/username/Documents/". If I move the documents folder, the link will continue to point to the old location, and will not be able to open anything. If I were to put a different folder in that location and rename it to "Documents", the symbolic link would then point to that new folder.

One advantage of symbolic links (relevant to the Dropbox case) is that they are (usually) transparent to applications. That is to say, if you have a program accessing a file or folder via symbolic link, it doesn't generally realize that it's using a link, and not accessing the file directly. In the case of Dropbox, if you create a symlink, Dropbox will think the files you link to are actually located in your Dropbox folder, and will synchronize them. If you were to use an alias, Dropbox would simply see that alias as one file, and would synchronize that file, but not whatever it points to.
0

#3 User is offline   bastion 

  • Power User
  • PipPipPipPip
  • Group: Members
  • Posts: 9,272
  • Joined: 14-October 04

Posted 05 January 2012 - 03:49 AM

View PostTyphoon14, on 04 January 2012 - 02:58 PM, said:

View Postpersistentcookie, on 04 January 2012 - 04:50 AM, said:

Can someone explain the difference between creating an alias to a folder vs. a symbolic link? Is there an advantage to one or the other? Most websites suggest the creation of symbolic links when using Dropbox, specifically. If symbolic links are better, can someone explain the procedure to me? I have a feeling I'm doing it backwards...Thanks


In a nutshell, aliases point to a file or folder, regardless of its location on the disk. If you move it, the alias will continue to point to it at its new location.
In contrast, symbolic links point to a path. For instance, I might have symbolic link that points to "/Users/username/Documents/". If I move the documents folder, the link will continue to point to the old location, and will not be able to open anything. If I were to put a different folder in that location and rename it to "Documents", the symbolic link would then point to that new folder.

One advantage of symbolic links (relevant to the Dropbox case) is that they are (usually) transparent to applications. That is to say, if you have a program accessing a file or folder via symbolic link, it doesn't generally realize that it's using a link, and not accessing the file directly. In the case of Dropbox, if you create a symlink, Dropbox will think the files you link to are actually located in your Dropbox folder, and will synchronize them. If you were to use an alias, Dropbox would simply see that alias as one file, and would synchronize that file, but not whatever it points to.


This is a nice writeup, but just incorrect enough to cause trouble in certain situations.

The description of the nature of a symlink is spot on. Effectively it's a text file whose contents are a path. There's a flag set in the directory information that tells the POSIX file-handling APIs (and anything built atop them) that when this file is addressed what should actually happen is that the file is read and the path it contains is what should actually be used. This happens under the application's radar; it takes some effort to interact with the symlink file itself.

Aliases are a bit more complex. They can reference an object in the file system either by a persistent ID or by path. Generally they will contain both pieces of information. An application developer can explicitly indicate to the OS which one to use when resolving; the default behavior was the use the ID but they changed over to preferring the path in, IIRC, 10.3. So if you move the thing it points to, and then put a new file with the same name in the old location it'll reference that new file. It'll reference the old file in the new location if you *don't* put a replacement in the original folder. Alias files started to get an overhaul in 10.6 that makes them even more "interesting." One feature of the alias that links don't have is that they can track things on unmounted volumes, mounting implicitly if possible and prompting you to attach the volume otherwise.

I think I've seen a GUI tool somewhere for creating symlinks but the traditional way to create them is at a command prompt.

ln -s /path/to/existing/file /path/to/alias/file

The ln command creates file system links. The -s argument tells it to create a symbolic link; the alternative is a hard link which a horse of a 3rd color. The first path is the thing you want the link to reference. The second path is optional and tells the command what file to create and where. If you don't provide that path, it will create a link with the same name as the reference file in the current working directory.

So, short form:

A symlink is a reference to a location, and whatever happens to be there at the time the link is resolved.
An alias is a reference to an object in the file system *or* to a location, and which is used is up to the developer of the application resolving it.
A hard link is essentially just the UNIX name for a directory entry pointing to a collection of blocks on the disk. More than one hard link can point to any such set of blocks. A file is considered deleted when no hard links to it exist.

Which one to use...depends a lot on the software that's going to be using it. Unfortunately it's not always obvious and as you can see from the summary there none is really a complete replacement for either of the others.
0

#4 User is offline   Typhoon14 

  • Veteran
  • PipPipPip
  • Group: Members
  • Posts: 2,966
  • Joined: 02-February 01

Posted 05 January 2012 - 05:51 AM

Good addition. I didn't realize aliases ever track by path. To be fair, 10.3 is probably the last time I actually used an alias for any part of my workflow.

One note I will make about the "transparency" of symlinks: It will break down on files if the application using the link does atomic saves (e.g., writes a new file with the modifications on top of the old file instead of appending to the old file). For instance, if I had moved /Users/username/Library/Preferences/com.company.app.plist to Dropbox, and created a symbolic link in the original location, and the application in question updates its preferences file atomically, it will delete the symlink, then write the original file in its place, bypassing Dropbox. The workaround for this would be to symlink the parent directory (although in this example, that would be the entire ~/Library/Preferences directory, which would not be ideal).
0

#5 User is offline   bastion 

  • Power User
  • PipPipPipPip
  • Group: Members
  • Posts: 9,272
  • Joined: 14-October 04

Posted 05 January 2012 - 07:58 AM

View PostTyphoon14, on 05 January 2012 - 05:51 AM, said:

Good addition. I didn't realize aliases ever track by path. To be fair, 10.3 is probably the last time I actually used an alias for any part of my workflow.

One note I will make about the "transparency" of symlinks: It will break down on files if the application using the link does atomic saves (e.g., writes a new file with the modifications on top of the old file instead of appending to the old file). For instance, if I had moved /Users/username/Library/Preferences/com.company.app.plist to Dropbox, and created a symbolic link in the original location, and the application in question updates its preferences file atomically, it will delete the symlink, then write the original file in its place, bypassing Dropbox. The workaround for this would be to symlink the parent directory (although in this example, that would be the entire ~/Library/Preferences directory, which would not be ideal).


Good warning to offer.

More on alias files: The meat of them is an opaque OS structure which is called an alias record. They were introduced in QuickTime - so movies could reference external resources - a little over 20 years ago, and then showed up in the user-oriented form of alias files with System 7. When an application asks the OS to create an alias record they can indicate that they want the record to store the file ID, the path, or both. Both is the default and has been as long as aliases have existed. Until 10.3 (again, IIRC) the file ID was the preferred mechanism used to resolve the alias. They changed it I think to make the behavior more consistent with that of symlinks - and note that Finder's presentation of symlinks is virtually identical to that for alias files.

Alias files have grown during the Mac OS X era because they contain a copy of the icon for the file they reference. This makes it easier for the user to identify, and doesn't require the target file to be on a mounted volume so the icon can be retrieved on-demand. Over the last few OS releases Apple has supported increasingly larger icons so the alias files grew as well, up to about half a MB in 10.5. So an alias file was traditionally a file with the alias record and icons in the resource fork and no data fork at all.

In 10.6 Apple introduced the replacement for the alias record; an opaque structure called "bookmark data." It's purposely not well-documented but it appears to be a superset of the information tracked by aliases and it's easier to use from Cocoa. They also expanded the structure of alias files; the resource fork is unchanged, but the data fork now has bookmark data referencing the same file. And for the moment alias files regularly get as large as a full MB. I fully expect the resource portion of alias files to go away in the future; I'd even predict that happens with the next major OS release. Typical, properly-written software shouldn't be affected at all. Software that by developer choice or necessity was explicitly interacting with the contents of the alias file will need to be updated by the time that happens.
0

#6 User is online   lauralou 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 1
  • Joined: 04-September 08

Posted 19 August 2012 - 09:04 PM

View Postpersistentcookie, on 04 January 2012 - 04:50 AM, said:

Can someone explain the difference between creating an alias to a folder vs. a symbolic link? Is there an advantage to one or the other? Most websites suggest the creation of symbolic links when using Dropbox, specifically. If symbolic links are better, can someone explain the procedure to me? I have a feeling I'm doing it backwards...Thanks


BEWARE OF ALIASES with Dropbox! (OSX 10.7.4) Because I wanted a way to retain my normal file structure, I researched how to accomplish this, and found information on symlinks. Unfortunately, I naively though that symlinks are the same as aliases (I hadn't seen this thread at that point.) I created aliases of the actual documents that were in the DB folder, then put those aliases into the original location of the things I had put in DB folder. But further researcher told me that aliases are NOT the same, so I deleted them in order to make symlinks. IN NORMAL OSX OPERATIONS, DELETING AN ALIAS DOES NOT DELETE THE ORIGINAL. But all the originals in DB got deleted EVERYWHERE. They were not in my Trash, and there were no previous versions o the web, as I hadn't worked on any of the docs, since I had only put them in DB a few hours earlier. I had to recover from a local hard disk Backup, which, most fortunately, I had. I lost an insignificant amount of data this time, but it could have been catastrophic. The DB folks should really highlight this to new users so they don't make this critical error.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users