I can’t count the number of times I’ve see this question asked on the internet. I probably receive two or three requests a day asking me for a script that can automatically delete files that are older than seven days.
So I’ve decided to make an article of it and show you just how easy it is to delete files based on age with WSH. I’m going to help you create a good base script that can be used by its self or expanded into a much larger script.
Since this code is most likely going to be used inside of another script I decided to write it in a modularized fashion. In other words, it’s going to be a series of subroutines that can easily be dropped into any other script.
To begin, we’ll connect to the FileSystemObject and create the subroutine that will perform the actual file deletion. A simple beginning looks like this:
numDays = 7
Set objfso = CreateObject("Scripting.FileSystemObject")
Set objFile = objFso.GetFile("C:\test.txt")
Sub DeleteOldFile(objFile, numDays)
dateFile = objFile.DateLastModified
dateToday = Now()
If dateFile <= dateToday Then
daysOld = dateToday - dateFile
If daysOld > numDays Then
objFile.Delete
End If
Else
WScript.Echo "Incorrect date stamp in", strFile
End If
End Sub
That’s exactly what you were thinking, right? Okay, it looks a lot harder than it really is. Here’s what we have going on in our subroutine.
The subroutine only requires two parameters.
The first is file object representing the file that we would like to delete. At this point you should know how to connect to the FileSystemObject and grab a file. If not, the first two lines aren’t too difficult to figure out—you only need to change the file path.
The second parameter is an integer representing the file age in days.
Next we establish two very important dates: the file’s Last Modified date and today’s date. It would be pretty tough to figure out a file’s age without those two pieces of information. The File object’s DateLastModified property and VBScript’s Now() function both return date type variables.
Because date types are special, they can be calculated much the same way you would a number. Adding or subtracting them results in a floating point number of days. So that’s exactly what we do to determine daysOld.
Finally, a simple If statement determines if the file is older than the given number of days (numDays). If it is, we use the File object’s Delete method. If it isn’t, we leave it alone.
I’ve also added a little error handling in there that will flag if a file’s date is newer than today’s date. That would indicate a problem in the file’s date stamp, or a change in the system time since the file was last modified.
When I create scripts I like to account for as many different scenarios as possible. This script is no different. It’s hard to say what kind of uses different people may have for something like this. That also means that there’s no telling what files they may try to delete.
In Windows you will receive an error any time you try to delete a file that is read-only. With that in mind we should attempt to work around that.
We could easily add an If statement to check the file’s attributes and change them whenever necessary, but that would be more work that is really required. There’s no point wasting space checking a file’s attributes when we can simply reset them before we delete. Let’s take a look at the code.
Sub DeleteOldFile(objFile, numDays)
dateFile = objFile.DateLastModified
dateToday = Now()
If dateFile <= dateToday Then
daysOld = dateToday - dateFile
If daysOld > numDays Then
objFile.Attributes = 0
objFile.Delete
End If
Else
WScript.Echo "Incorrect date stamp in", strFile
End If
End Sub
Quite simply we’re using the File object’s Attributes property to reset any attributes prior to calling the Delete method. There’s no harm in setting this attribute in every case so there’s no need to create any If statement at all.
There is still one last scenario to consider—an undeletable file. Since we’ve reset the file’s attributes, the only scenario left that would prevent a file from being deleted is if the file was currently in use.
This would raise an error and cause our script to quit. For obvious reasons, we don’t want that to happen. We want our script to continue on to the next file. In order for that to happen, we need to turn off error handling with the On Error Resume Next statement.
I’ve made a few final changes to complete the DeleteOldFile subroutine. These changes are mostly for error-handling purposes.
First, I’ve made sure to clear the Err object after entering the subroutine. Then I’ve done a simple error check to see if the object file was able to be deleted. A 0 return code indicates a successful deletion, anything else indicates an error. For instance, an error code of 70 would indicate that the target file was in use.
If there was an error, I can safely assume it’s because the file is in use. That means that the file should be scheduled for deletion after the next reboot. We’ll get in to that later. For now, just pass the file path to the RemoveOnReboot subroutine that we’ll be creating later.
Most of the requests I’ve gotten were from people looking for a script that could be used as a Scheduled Task for automatically removing old backups from an archive folder. With that purpose in mind, I decided to take this script a step further and add a subroutine that would allow the script to move through all of the files in a specified folder.
Sub CheckFolder(objFolder, numDays)
Set colFiles = objFolder.Files
If colFiles.Count > 0 Then
For Each objFile In colFiles
Call DeleteOldFile(objFile, numDays)
Next
Else
WScript.Echo "No files in folder", objFolder.Path
End If
End Sub
The subroutine is pretty simple. I use the Files property to return a collection of files in the specified folder location. A simple check ensures that there were indeed files found and then call the DeleteOldFile method for each of them.
To add a little flexibility, I’ve added numDays as a parameter for this subroutine. That allows you to specify a different age for each folder.
Let’s suppose for a minute that someone wanted to clean an entire folder tree. That means they would want to delete files recursively, or in all subfolders, as well. We can add recursion quite easily.
Sub CheckFolder(objFolder, numDays, bRecurse)
Set colFiles = objFolder.Files
If colFiles.Count > 0 Then
For Each objFile In colFiles
Call DeleteOldFile(objFile, numDays)
Next
Else
WScript.Echo "No files in folder", objFolder.Path
End If
If bRecurse Then
Set colSubfolders = objFolder.SubFolders
If colSubfolders.Count > 0 Then
For Each SubFolder In colSubfolders
CheckFolder SubFolder, numDays, True
Next
End If
End If
End Sub
Again keeping flexibility in mind, I’ve added bRecurse as a parameter to the subroutine. bRecurse is a Boolean value the indicates whether or not the folder should be processed with recursion.
If the bRecurse value is set to true, the SubFolders property is called to return a colSubfolders collection. A quick check makes sure that the count is not equal to 0 before passing each subfolder back to the CheckFolder subroutine.
Now we can complete the script by making a call to the CheckFolder subroutine. Just add a line to the beginning of your script.
numDays = 7
strPath = "C:\Windows\Temp"
Set objfso = CreateObject("Scripting.FileSystemObject")
If objfso.FolderExists(strPath) Then
Set objFolder = objfso.GetFolder(strPath)
Call CheckFolder(objFolder, numDays, True)
Else
WScript.Echo "The specified folder", strPath, "does not exist"
End If
Of course, you probably know me by now. I would never stop there. I’ve implemented the FileSystemObject’s FolderExists method to verify the folder path before trying to connect to the Folder object.
In the above example, I’ve set the script to recursively delete all files in the Windows Temp folder that have not been modified in the last seven days.
Now that we’ve got a working script, let’s backtrack slightly and fix one unresolved issue. We still need to create a subroutine that will schedule undeletable files for removal at the next reboot.
We’ve already established that if a file is currently in use it must be deleted upon reboot. To schedule a file for deletion it needs to be added to the registry's PendingFileRenameOperations value located under the Session Manager key for the current control set. The exact path is in the script example below and will not change.
The PendingFileRenameOperations value is a multi-string value that contains line pairs representing files that need to be renamed, copied, or deleted. Each file appears on its own line. The first of each line pair is the source and the second is the destination.
The only way to work with multi-string value types in WSH is by using WMI’s Standard Registry Provider. We can connect to it like this:
Sub RemoveOnReboot(strFile)
Const HKLM = &H80000002
strComputer = "."
Set objReg = GetObject("winmgmts:" & strComputer & _
We begin our subroutine by establishing a few constants. The first is a hex value that represents the HKEY_LOCAL_MACHINE hive in the Windows registry. The second is used to tell WMI that we want to access the local computer.
After using the GetObject method to connect to the registry provider, we can use the GetMultiStringValue method to read the value’s current contents and return the value data as an array named arrValues.
Neither WSH nor WMI provide a method of checking whether or not a registry value exists. Here I’ve provided a small workaround. It turns out that the registry provider’s Get methods return NULL if a value does not exist and EMPTY if a value exists without any data. However, since the GetMultiStringValue returns an array. An array of empty strings is still considered to be null so it will return NULL in either case.
Now a simple check will indicate whether or not there is currently any data.
If IsNull(arrValues) Then
arrValues = Array("\??\" & strFile, "")
If arrValues is null we create an array with our file’s path. Then, we add an empty string for the second element. You’ll also notice that I’ve prefixed “\??\” to the file path. This is required.
If there is already data in that value, we should read the data first and then append to it.
Here I’ve used a ReDim statement to add two elements to the returned array. The Preserve flag tells VBS to retain the current information. In the next two lines I assign my data to the two new elements.
Look at how I’ve used the UBound function to determine my array boundaries and the position of the last two elements. I’ve done this because the initial size of the array could be different every time the subroutine is called.
We finish up by deleting the existing key if it is present and then write our newly formatted array back to the registry.
You should be able to find many different uses for this type of script and there is a lot of room for improvement as well. Consider adding some logging or better error-handling. What would happen if you used the DateCreated or DateLastAccessed method instead of DateLastModified?
I hope I’ve been able to shed a little light on the subject of age-based file deletion and maybe prevented a question or two. Until next time, keep coding!
Windows Scripting 
An Introduction to Files and Folders in WSH
