Relative shortcuts for Windows

What is this thing?

Relative lets you create relative shortcuts in Windows. As the name implies, relative shortcuts can be moved along with their parent directory tree and still point to the same location within the tree.

The current version of Relative works with Windows XP, Vista, and Windows 7. It's too painful for me to look at Windows 8 in order to test the program, so please let me know if that works.

UPDATE: Entity tmpl33 informs me that it works fine with Windows 8.

Usage

Right-click on any file or folder. From the context menu, select "Create relative shortcut...". A file browsing window will appear. Navigate to the location where you want to create your shortcut and click "Ok".

Command line usage

If you put the installation directory on your PATH, you can use the program from the command line:

	relative targetPath shortcutPath

For example:

	relative a/b/c/someTarget.txt a/b/d/myshortcut 

The relative shortcut path in this case would turn out to be:

	../c/someTarget.txt

Limitations

If you move the shortcut file or the target file, the shortcut obviously won't work. You can modify the shortcut path from its Properties panel, but it's usually easier to create a new one.

You can't create a shortcut to a file that doesn't have an associated program of some kind. In other words, if you can't double-click on a file and open it with something, you won't be able to create a relative shortcut.

Although you can create shortcuts using the command line, they are only usable from Explorer. You can't, for example, use one as a parameter to another command that expects to operate on the target.

The program doesn't support Windows unicode (UTF16) filenames yet, but I plan to do that Real Soon Now.

Download

Relative-0.92

How it works

The program creates a windows shortcut file. This is a file with a special hidden ".lnk" extension. It's the same type of file you create using the "Create shortcuts here" context menu in Explorer. The target of the shortcut is the program "Explorer.exe". The program parameter is the relative path to the target. Relative figures out the relative path from the location selected for the shortcut to the target file.

What's wrong with "mklink"?

Starting with Windows Vista, there is a command line function:

	mklink newSymbolicLink targetPath 

If you try this, it appears to do exactly what Relative does (only with the parameter order reversed.) If you move a symbolic link to another location where the relative path makes sense, it will work there as well. And symbolic links can be used as parameters to other commands, unlike the shortcuts created by Relative. So what's not to like? Unfortunately, at least two big things:

  1. If you copy symbolic links with Explorer or a directory tree that contains such links, the link files that should be in the copy are replaced by their targets! This is a fatal design flaw.
  2. If you backup Windows machines with a remote linux file server, symbolic links are copied as zero-length files with no information about how to recreate them when the backup is restored. Of course, that's just a limitation of Samba on Linux. So next I tried using Microsoft's backup program that comes with Windows 7. I created a small tree of files and folders that contained some symbolic links and backed them up. Then I restored the backup to another location. The result was such a mess, I'm at a loss for words to describe it.

It seems that the Windows developers wanted to have something like linux symbolic links, but since they are trained in a bubble universe, had no accurate conception of how they're supposed to work.

Comments, complaints, or suggestions

Let me know...