Microsoft

Mapping drive letters to local nested folders

If you are tired of clicking through a convoluted file system on your hard drive, check out this Daily Drill Down series from Greg Shultz. He provides a handy VBScript file you can use to map your local folders to a drive letter.


I’m going to show you here how to create a script with the VBScript scripting language that will allow you to quickly and easily map drive letters to local nested folders from within the Windows GUI. In my follow-up Daily Drill Down, I’ll go through the script line-by-line and explain in layman’s terms how it works. This means that not only will you come away from this Daily Drill Down series with an extremely useful tool, but you’ll also pick up some valuable scripting techniques that you can employ when you create your own Windows Script Host scripts.

Getting to the root
If you regularly work with files stored in shared folders on a network, chances are that you’ve used Windows’ Map Network Drive command to map a drive letter to a shared folder. Doing so makes it easy to quickly access shared folders on the network—you just open My Computer and click the drive letter. However, the real advantage of mapping a drive letter comes when you need to access a data file that’s stored in a shared network folder from within an application’s Open or Save As dialog box. Rather than having to traverse the network using the dialog box’s limited navigation features, you just select the drive letter. What could be easier?

Now, if you work with and store data on your local hard disk, chances are you have a very detailed folder structure to keep things organized. For example, you may have a folder for each of your projects and each project may have several subfolders with more folders nested inside them. In fact, it’s not inconceivable that you could have folders nested 10 or more levels deep. This means that you probably spend a lot of time traversing nested folders on your local hard disk from within both My Computer and your application’s Open and Save As dialog boxes.

Wouldn’t it be nice if you could map a drive letter to a nested subfolder on your hard disk? Then you could access nested subfolders just as easily as you can access shared folders on the network.

The Subst command
Fortunately, there’s an old DOS command, Subst, that’s designed to associate a path to a folder with a drive letter. Essentially, the Subst command allows you to map drive letters to folders on your local hard disk just like the Map Network Drive command lets you map drive letters to shared folders on the network. Regrettably, the Subst command is a DOS-based command and there isn’t a comparable command built into the Windows GUI. If you want to take advantage of the Subst command, you have to shell out to an MS-DOS Prompt in Windows 9x/Me or to a Command Prompt in Windows NT/2000 and then manually type the Subst command along with the path to the folder to which you want to assign the drive letter. This can be an extremely tedious operation—especially if the folder is nested several levels deep. One typo and the command will fail.

However, using the Windows Script Host and its scripting languages, you can develop a tool to map a drive letter to a local nested folder from within the Windows GUI. Furthermore, this solution will work on systems running Windows 95, Windows 98, Windows Me, Windows NT, and Windows 2000.

Prerequisites
In order to create and use this script, your system must meet two requirements. First, this script requires that your system is running the Windows Script Host 2.0 package. You can download this package from the Microsoft Windows Script Technologies site. Just follow the links to the Windows Script Host Downloads section. The Windows Script package, called Windows Script 5.5, includes Windows Script Host 2.0, VBScript 5.5, and JScript 5.5. Also, keep in mind that there are two versions of the package, one for Windows 2000 and one for Windows 95/98/Me/NT.

Second, the script requires files provided by the Active Desktop and the newer versions of the Windows operating system. This means that if you’re using Windows 98/Me or Windows 2000, you’re all set for this second requirement.

If you’re running Windows 95 or Windows NT 4.0, you must have installed Internet Explorer 4.x and the Active Desktop feature, which adds the needed files to your system. Keep in mind that the Active Desktop feature is not included in Internet Explorer 5.x. This means that if you bypassed Internet Explorer 4.x and the Active Desktop feature and went straight to Internet Explorer 5.x, you won’t be able to run this script. For more detailed information on how to remedy this situation, see the Microsoft Knowledge Base article "How to Install the Windows Desktop Update with Internet Explorer 5.x."

Unfortunately, you can no longer download Internet Explorer 4.x from Microsoft’s Internet Explorer site. You can, however, download the standard version of Internet Explorer 4.01, which includes the Active Desktop feature, from Evolt.org’s Browser Archive.

Map Local Drive script overview
Before you actually begin creating the Map Local Drive script, let me take a few moments to give you a general overview of the script. To begin with, this script mimics Windows’ Map Network Drive command as much as possible. So if you know how to use the Map Network Drive command, you have a good idea of how the Map Local Drive script works.

Now, if you’ve been following along with my tutorial series of Daily Drill Downs on using Windows Script Host and VBScript, you know that all of the scripts I’ve presented so far have used a top-down design, meaning that the script is designed as a single routine in which the execution flows from the top of the script straight through to the bottom. This design worked well because the tasks performed by the previous scripts were pretty straightforward.

The Map Local Drive script is a bit more complex. To begin with, it actually performs three different operations. Furthermore, it employs a lot of error handling schemes in order to keep the script from running off into left field if the user accidentally provides erroneous input.

The script is divided into three procedures, or subroutines, and four functions in addition to the main section, which acts as the script’s driver. Each of the three subroutines corresponds to a specific operation that the Map Local Drive script performs—namely, mapping a drive letter, disconnecting mapped drives, and viewing existing mappings. Furthermore, several of these subroutines need access to the same functions in order to do their jobs. For example, both the mapping and disconnecting subroutines need to be able to prompt for and verify drive letters. Those tasks have been separated into the GetDrvLetter and DrvExists functions, which each subroutine can access independently.

With this in mind, let’s create the Map Local Drive script. I’ll go into more detail on how the various subroutines and functions interact with each other in a follow-up Daily Drill Down.

Creating the Map Local Drive script
Creating the Map Local Drive script is relatively easy but will take some time due to its length. To begin, launch Notepad or SynEdit (if you’ve set it up as your Windows Script Host IDE) and type the Map Local Drive script shown in Listing A. Be sure that you type all the commands exactly as shown. If you don’t, the script will not work correctly. When you’ve finished, save the file as MapLocalDrive.vbs.

Note
If typing in lines of code isn’t your cup of tea, don’t worry; the MapLocalDrive.vbs script is available for download. To download the script, just click here.

 

Conclusion
That’s it! One hundred and eighteen lines of code later, you have a handy tool you can use to map drive letters to your local files. However, while it is one thing to have the code in front of you, it is quite another to understand what function each line performs. So, in my follow-up Daily Drill Down, I will break down each section of code into logical subroutines. Ultimately, the goal is to give you the necessary background to create your own scripts to use for whatever function you would like to automate.

About Greg Shultz

Greg Shultz is a freelance Technical Writer. Previously, he has worked as Documentation Specialist in the software industry, a Technical Support Specialist in educational industry, and a Technical Journalist in the computer publishing industry.

Editor's Picks

Free Newsletters, In your Inbox