Saturday, July 12, 2003


I like to work at the command line. Indeed, for some of the work I’m doing right
now, I have to, since our build process is command-line driven. But I have a particular
directory structure that I like to use to put all my files that need backing up in
one place. Unfortunately, that means that from the command line I’d have to
work with paths like this:

C:\data\work\consulting\28 – FooCustomer\sources\build

Which is a pain to type.

I’ve been using the subst command for a long time to address the problem. It
lets you create a drive letter that actually maps to a particular location on your
hard drive. So if I do this

Subst S: "C:\data\work\consulting\28 –

I can now simply work from the S drive and I’ll be in my build directory. This
has been very handy for some long-distance music collaboration that I’ve been
doing, too, since the digital music program I use (Cakewalk) likes to embed absolute
paths in the files it saves. If my partner and I both map some drive to the directory
that we like to use, we can fool Cakewalk into working, making it easy for us to share

The problem with this approach is that it doesn’t work for anyone other than
the currently logged in user. This wasn’t a problem until recently, when I wanted
to run some automated setup as part of the build process. Because that setup does
things like set up a database, and because the database is a service that runs non-interactively,
it means that I had to go back to using the actual path off the C drive in my config
files. Being a programmer, this horrible lack of symmetry – using the S drive
in the build script except for the bits
that deal with the database – really grated on me. Not to mention that using
two different paths depending on what piece I was dealing with confused both me and
my source control program.

That’s when I went searching for one of my favorite tools: linkd. Linkd lets
you create symbolic links in your filesystem, just like under Unix. A symbolic link
is a directory that actually redirects you to somewhere else on the harddrive. So
by running

Linkd \etc\build "C:\data\work\consulting\28
– FooCustomer\sources\build"

I now have a directory on my C drive called \etc\build that’s actually a reference
off to some other directory. Any changes I make in one place are reflected in the
other – and unlike .lnk files, it works at the file system level, meaning it’ll
work from the command line, and is visible to all sessions on the machine, not just
the ones in the current session. It quite literally just gives two names to the same

I could have chosen to use it the other way, too. Rather than creating a link to a
directory within the one directory that I back up, I could have used it to build up
my backup directory by creating links off to all the places that contain data I want
to back up.

I was able to find linkd and many other great tools here.


  1. I suppose linkd creates an 'hardlink'. Be VERY careful with hardlinks, they're not exactly like symbolic links. When you delete an hardlink (in explorer for example), then you delete the directory you're linking to! You'll have to unlink the hardlink. Under unix, just the symbolic link is deleted, not the directory linked to.

  2. Ah yes, I blogged about this same topic:

    There are a couple of other tools that accomplish this as well. I've used Junction from Sysinternals:
    I also just ran across Junction Point Magic, which I haven't tried yet but gives you a GUI for creating junction points:
    Looks promising.

  3. Cool. Thanks for the extra info, guys.

  4. Thats not what hardlinks are conceived to do.

    Shortcuts usually fulfill that purpose.

    Hardlinks are for other, more advanced stuff.

  5. VictorV:

    No, they are not hard links. "rmdir /Q /S directory", for example, will not delete the targets of junctions it finds below "directory". (I am not sure what it would do if "directory" were a junction, but that is another matter...) Explorer (and "del /s") will delete the contents of the target because Explorer walks the directory tree when doing it's delete, and it does not check if a "directory" entry is a junction before it performs this walk. You must be carefule with any application which walks the directory tree deleting things without checking if a directory is a symbolic link (even in Unix).


    "shortcuts" will definitely not fulfill that purpose. "shortcuts" are implimented at the application level: that is, the application must be aware of shortcuts, watch for them, and process them correctly. Most applications do not do this. junctions, as with unix links, are implemented at the OS/file system level, so applications can be blissfully unaware of their existence (though you must be careful with applications which delete directory trees, as explained above).

  6. Need this tool to fix my SYSVOL directory on one of my DC's