Making Symlinks to a Directory Work in Dreamweaver CS5.5 on Snow Leopard: Hard Link Style

NOTE: This post is about symlinks and hardlinks as they relate to Adobe Dreamweaver CS 5,5 running on Mac OS X 10.6+ but also applies to very earlier version of Dreamweaver. ALSO NOTE: This technique totally works but be super careful. There is a reason links are treated in special way.

They work in every other IDE, but symlinks do not work in Dreamweaver. I'm sure there must be a reason, but I almost don't care. I want them to work so I can deal with directory structures that use them.

Scroll down to the SOLUTION to bypass all my comentary.

In general, symlinks can result in circular dependencies that can really mess things up but then again, programmers write infinite loops sometimes and seem to resolve them, so what gives Dreamweaver?

I came across this issue when researching sencha touch and making my way through a webinar. The presenter recommended a symlink for linking to the main API and it clicked - how perfect. So I stopped and configured my directory structure the same way and then looked at it in Dreamweaver :(

Dreamweaver hated this and instead of showing me the directory's content, it told me it couldn't find an editor for the file. Ugh.

Hard Linking vs. Symlinking / Shortcuts

A symlink is like a shortcut in Windows without the terribleness of Windows. Windows adds .lnk to the shortcut and doing so prevents the usefulness of treating the shortcut as if it were the actual file or directory.

To create a symlink, run a command like the one below:

$> ln -s /Users/scoobydoo/lib/apache-commons/commons-lang-1.2-4.jar commons-lang.jar

This creates a symlink (notice the -s) to commons-lang-1.2-4.jar named commons-lang.jar. This allows me to swap out different versions of commons-lang yet always refer to it as commons-lang.jar. For the record, that's probably a terrible idea, but you get my point.

Dreamweaver doesn't like this. In fact, it's quite hillarious what Dreamweaver actually does. If you open this link in Dreamweaver, it actually shows you - in a text file - the path to the linked file. Well, that is just cute. Useless, but cute.


Hardlinks: A hardlink isn't really a shortcut but rather a direct link to a file's actual inode. Generally speaking hardlinks are not possible to directories, but Mac OSX allows it. Unfortunately it provides no means to actually make the link...big sad face.

With a hardlink, if you delete the "original" file, any hardlinks that were created still point to the inode, which means that the location in memory can still be accessed.  That's because deleting a file really translates to "unlinking a file." This is referred to as "awesome."

Let's try it out:

$> mkdir t $> cd t $> mkdir lib $> touch original.txt $> cd lib $> ln ../original.txt copy.txt $> cd .. $> rm original.txt $> cf lib $> ls

You'll still see copy.txt because copy.txt does not link to original.txt, it "points" to the inode that original.txt pointed to. Typically, this only works with files and not directories.

Dreamweaver is fine with hardlinks because hardlinks in a way, aren't links, they are just files that point the same location as another filename.

The problem we are left with is how can we create a hardlink to a directory so that Dreamweaver won't flip out?

Easy, write a tiny C program. For real.

Greg Miller wrote pretty cool article Exploring Leopard with DTrace: How to use DTrace for debugging and exploration that includes the code I'm about to show you.

Copy/paste this code into a text editor and save it as hard-linkd.c (or something else).

#include <unistd.h> #include <stdio.h> int main(int argc, char *argv[]) { if (argc != 3) return 1; int ret = link(argv[1], argv[2]); if (ret != 0) perror("link"); return ret; }

To compile it:

$> gcc -o hard-linkd hard-linkd.c -Wall $> cp hard-linkd /usr/local/bin

Now you can use hard-linkd to hard link to a directory and make Dreamweaver happy.

$> hard-linkd src-directory dest-directory

I did this. It works. All is right again.

SFTP Connection Problems from Dreamweaver: Cannot Make Connection to Host

If you were once able to connect to your SFTP server from Dreamweaver but now suddenly you cannot and the error message is something useless like "An FTP Error Occurred - Cannot Make Connection to Host" then the likely cause is that the servers ssh host key changed. Why?

In my case, our hosting company built us a new VM and when we were ready to start using it, they reassigned the same IPs from the old VM to the new VM. We took this approach instead of changing the DNS entries because it would be less disruptive to our clients.

The problem is the SSH host is different and therefore the SSH host key is different. You can verify this by opening your SSH client and connecting to the new server (with the same IP address or host name). When the SSH client sees that the host file is changed, it presents you with a message asking you to accept it. As always, once you accept it, it adds an entry to your known_hosts file located in .ssh/known_hosts if you're on a Mac/*nix and somewhere else if you're on Windows.

This enables all SSH clients to work fine with your new host...except Dreamweaver. Dreamweaver, as it turns out, maintains it's own ssh_hosts file that needs to be updated and it WILL NOT tell you. It will simply "fail to connect" when it sees that the host keys don't match and like a freshman programmer, gives you no reason as to why.

On Mac/*nix the file is located in:

/Users/user.name/Library/Application Support/Adobe/Dreamweaver CS5.5/en_US/Configuration/ssh_hosts

Or, if you're using an old version of Dreamweaver somewhere in the Application Support folder. Look around, you'll find it.

DELETE IT! Or, remove the offending entry, like I did.

All better. Hope this helps. I plan on submitting a bug to Adobe.

Downgrading Subversion for Dreamweaver CS4: Or Just To Do It

We use subversion everyday to manage updates or other changes to our projects but one problem I encounter from time to time is conflicting client versions on the same machine. Normally, this shouldn't ever happen but it will happen in several scenarios. One example is when I use the command line on my Mac to perform an initial checkout or checkin and then switch over to Dreamweaver CS4 to manage day-to-day updates. If you want to know the version of subversion your system uses, the following command from your terminal:

svn --version

As you can see from the screen shot above, the version I am running is 1.6.16.

Dreamweaver CS4 does not run subversion 1.6.16. It runs version 1.4.5. Why it doesn't just use my system's svn program is beyond me but since 1.4 is incompatible with 1.6, something's got to give.

A quick mention about Dreamwaver CS5.5: It uses svn version 1.6.9 and since 1.6 is the most recent release - as of this writing - you won't have to worry about downgrading.


Download this Python script from Apache that you can run to change the metadata version. I'm saving it to my desktop so if you just want to copy/paste, do the same.


Run the script with --help flag for information on how to run it.

To change the version for your project, run the following command:

python ~/Desktop/change-svn-wc-format.py . 1.4

The dot between the command and the 1.4 is the path to the project under version control. Since I was in the root directory of my project when I ran the command, the path was simply a dot. 1.4 is the version I want the project svn converted to.

That's it. Switch to over Dreamweaver and you're now free to commit and perform other svn commands on your site.

More Information

The incompatibility issue is no secret. Both Apache and Adobe have pages devoted to working around it. check out the pages below for a more detailed explanation.