How Can I Determine if a File Exists and, if It Does, Exit the Script?

June 20th, 2005

Hey, Scripting Guy! Question

Hey, Scripting Guy! How can I check to see if a particular file exists and, if it does, exit the script?

— TO

Spacer Hey, Scripting Guy! Answer Script Center

Hey, TO. There are at least two ways to check for the existence of a file (that's the real key here; exiting the script is easy). One of these approaches uses the FileSystemObject and the other uses WMI, and we're going to show you both methods today. Why? Well, that way if anyone comes by and asks us to help them with something we can say, "Wow, we'd like to, but we have to finish this column, and because we're showing people two scripts, well, that could take awhile."

OK, so that's only partly true: there are actually a couple valid reasons why you might choose one approach over the other. People generally find the FileSystemObject a bit easier to script; the only problem is that the FileSystemObject is designed to work solely on the local computer. WMI scripts tend to be a tad bit more complicated (although, as you'll see, they're still pretty easy), but WMI scripts can work with remote computers just as easily as they can the local computer. What does that mean? It means that, if you're working on the local computer, you might want to use the FileSystemObject. If you're working against a remote computer you need to use WMI.

In the grand tradition of the Scripting Guys let's do the easy one first. Let's take a look at a FileSystemObject script that checks for the existence of the file C:\Scripts\Test.txt. If the file is found the script exits; if the file is not found then the script displays a message to that effect.

Here's the script:

Set objFSO = CreateObject("Scripting.FileSystemObject")          
If objFSO.FileExists("C:\Scripts\Test.txt") Then     Wscript.Quit Else     Wscript.Echo "The file does not exist." End If

We told you it was easy. We begin by creating an instance of the Scripting.FileSystemObject and then call the FileExists method, passing the method the complete path to the file in question. If FileExists returns True that means the file was found; at that point we then use Wscript.Quit to exit the script. If FileExists is not found we then use this line of code to echo back our failure to find the file:

Wscript.Echo "The file does not exist."

That's pretty much all we have to do.

Incidentally, it's a good idea to use the FileExists method any time you're working with the FileSystemObject. The FileSystemObject is very powerful, but also very sensitive: it just falls to pieces when things go wrong. Worst of all, even using On Error Resume Next won't help; if the FileSystemObject tries to work with a non-existent file or folder your scripts are likely to crash even if you use On Error Resume Next. The way to work around that problem? Just use FileExists (or its companion method, FolderExists) before trying to bind to a file or folder.

OK, well, that's all for today – oh, that's right, we said we'd show you two scripts, didn't we? (What were we thinking?) As we noted, you can also check for the existence of a file using WMI. The nice thing about using WMI is that the same script can run against remote computers as well as local computers; all you have to do is change the name of the computer and have at it.

Here's a WMI script that checks for the existence of C:\Scripts\Test.txt and, if the file is found, exits:

strComputer = "."          
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
          
Set colFiles = objWMIService.ExecQuery _     ("Select * From CIM_Datafile Where Name = 'C:\\Scripts\\Test.txt'")
          
If colFiles.Count > 0 Then     Wscript.Quit Else     Wscript.Echo "The file does not exist." End If

Like we said, a tad bit more complicated, but nothing that you shouldn't be able to handle. We begin by setting the value of the variable strComputer to a dot; in the wonderful world of WMI the dot represents the local computer. But didn't we say that this same script could be used against remote computers? Yes, we did, and that's a simple enough task: just set the value of strComputer to the name of that remote computer. For example, this line of code will cause the script to run against the computer atl-fs-01:

strComputer = "atl-fs-01"

Next we connect to the WMI service, then use the ExecQuery method to select all instances of the CIM_Datafile class where the Name property is equal to C:\\Scripts\\Test.txt. And don't panic, you haven't suddenly been afflicted with double vision. In WMI the \ is a reserved character; that means any time a \ appears in a query the character must be "escaped," which simply means prefacing the \ with a second \. Thus a file path like C:\Scripts\Test.txt gets written out as C:\\Scripts\\Test.txt. Hey, as long as it works, right?

Note. By the way, this could be worse. For example, suppose we had a path like \\atl-fs-01\public\scripts. That would get written out like so: \\\\atl-fs-01\\public\\scripts, with every single \ doubled up.

Our query returns a collection consisting of all the files on the computer named C:\Scripts\Test.txt. (Needless to say, there can either be one such file or no such files.) To determine whether or not the file was found we check the Count property of the returned collection. If Count is greater than 0 that means the file was found; in turn we call Wscript.Quit and exit the script. If the Count is not greater than 0 than no such file could be found and we echo a message to that effect.

So there you have it: not one but two ways to determine whether a file exists and, if it does, exit the script. Wow, no doubt someday people will be saying, "Where were you on the day the Scripting Guys showed us two ways to determine whether a file exists?" Until then, just use whichever script makes the most sense for you.