Virtual Subst makes it easy to quickly access often used files

Since W2k, NTFS supports junction points which are similar to symbolic links.

http://support.microsoft.com/kb/205524

Actually DFS Links have been around since Windows NT 4

I like the antiquated approach. My mind just deals with the archiving system in place. Any time I try to modernize the approach, it just ends up bugging the crap out of me.

Mark Russinovich has had a wrapper to this for years ..

http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx

If you want to create or delete a junction, use Junction like this:

Usage: junction [-d] []

To delete a junction specify the -d switch and the junction name.

or check out this shell extension which gives you quick right-click access to hardlinks, junctions, and now in vista symbolic links...
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html

i personally highly prefer the drive letter scheme. and if i were so inclined.. i could still mount all my other drives under my root in C: too. with linux/unix everything necessarily has to go under /, generally in my experience as folder in /mnt.

so why exactly are drive letters lame and antiquated??? can you actually back it up or is it because its uber cool to call anything related to microsoft lame?

bad form guys.. bad form. can we someday keep the microsoft bashing limited to the actually warranted variety? pretty please?

I think the "antiquated" part was about subst, which has been around since I think Win95, if not earlier. The original post actually points to a wrapper (I assume) around subst.exe, which is a command-line tool to do just this.

Beware of junction points and other arcane NTFS features not directly supported in Explorer -- you might confuse Windows if you e.g. link c:\foo\bar as c:\foo\baz, and when you check the folder size of foo it's actually twice as big as what it takes up on disk...

> so why exactly are drive letters lame and antiquated???

Because they create an artificial constraint on both the number and naming of root-level directories, mounts, etc.

Can't we already do this with drive mappings and even shortcuts? How is this needed?

@James: The behavior you speak of only happens if you do a hard link. A junction does not do what you describe.. try it and see.

BTW, what is the behavior of linux in this regard between hard link and symlink? I havent checked yet.

@Dave Newton: What artificial constraint do you mean? Like I mentioned in my previous comment, you dont have to mount your drives as a letter... Since Win2000 you have been able to easily mount drives/partitions using junctions right from within Disk Management. Youre not limited in numbers at all.

Naming? ok yea.. You're limited to using letters for 'root' level mounts. Granted. Still dont see whats so lame and antiquated about that.. if you treat 'C:' as 'root-level' instead, conceptually you can achieve the exact same thing as linux and mount everything under /.. Am i missing something?

I could make the argument that linux is the one which is more limited regarding drive letters.. In windows you can have up to 26 different root file hierarchies, and in linux youre limited to exactly one.

The article implies that drive letters are antiquated simply because they were also in CP/M.. What a lame argument! CP/M provided OS level functions for file IO on disk, that concept must be antiquated too then.

Somebody tell me if im just all wrong and there is an actually valid reason to call drive letters lame.

@Harry: Drive mappings are network based, and you have to have a network share. Its not that Virtual Subst is needed.. as someone mentioned before subst has been around for a while, this is just a wrapper. I'm guessing subst would get you better performance than mapping a local network share though, but Im not sure about that.

drive letters tell you exactly where the data is located and help track down physical problems with the drives and replace them when they're going bad.

What? You've never lost a hard drive? Stick around for a while...