How to Monitor a Windows Folder for New Files and Take Action

The files are in a constant state of flow on any operating system. Sometimes they are created, sometimes they are deleted, sometimes they are changed, and these are normal things for an operating system. Sometimes when a file is modified, it can cause instability in another application that depends on it, such as modifying a port number in a properties file, a parameter in a deployment manifest, or even code correction. in production without going through source code control.

As part of managing these operating systems, engineers need a way to monitor what is happening to these critical files and take action when something happens. Enter .NET FileSystemWatcher class and PowerShell.

In .NET and .NET Core, FileSystemWatcher is a class that resides in the System.IO namespace and monitors files. In PowerShell, this can be very useful, especially when combined with other PowerShell functions.

Instantiating FileSystemWatcher

Instantiate this class in PowerShell by running $ watcher = New-Object System.IO.FileSystemWatcher. Once you’re done, you need to tell them what folder to look at. To do this, set the Path parameter of the FileSystemWatcher object to the path of the folder you want it to monitor. If you have a folder in Windows called WatchThisFolder under C: , you must set FileSystemWatcher on it by running $ watcher.Path = ‘C: WatchThisFolder’.

Since this class is also in .NET Core, you can do all of this on a Linux or Mac OS system in the same way as you would on a Windows system. For example, if you had a folder on Ubuntu Linux called WatchThisFolder under your current user directory, you would run $ watcher.Path = ‘/ home / ubuntu / WatchThisFolder’.

The rest of the code samples in this article work on either platform without any modifications.

Triggering events from FileSystemWatcher

Now that you have a new FileSystemWatcher object, you can take a look under the hood and try to figure it out. To see the specific types of file system events that FileSystemWatcher is monitoring, enter $ watcher | Get-Member -MemberType event. Get-Member shows everything that the object passed to it contains, and by adding the MemberType filter, you can see a certain category, in this case, events.

These events are:

Amended
Created
Deleted
Thrown
Error
Renowned

When one or more of these FileSystemWatcher events are detected on the path that the object is set to monitor, the observer object triggers an external event, for which you can define actions.

Now that the observer object knows what to monitor and you know what events it is monitoring, you need to configure it to trigger an event when an action is detected. To do this, run $ watcher.EnableRaisingEvents = $ true. Think of this flag as an on / off switch for $ watcher: if the switch is off, nothing will happen if changes are made. You can also ask it to examine files and folders nested under the one defined in the path by changing the IncludeSubdirectories flag to true in the same way as you did for the EnableRaisingEvents flag.

Definition of actions to be undertaken

Once the observer object is configured, you must give it an action to perform once this change is detected. It can be as simple as writing to a system log, or as drastic as triggering an instance replacement with clean source code extraction. To get started, you need to define an action block in the code. Here is one that writes to the console:

$ action = {
$ path = $ event.SourceEventArgs.FullPath
$ name = $ event.SourceEventArgs.Name
$ changetype = $ event.SourceEventArgs.ChangeType
Write-Host “File $ name at path $ path was $ changetype to $ (get-date)”
}

You can see that this code extracts variables from the event using the variable $ event, which is created for you when the event is created by the observer object. As soon as the event ends, the variable also ends, which means that it will only contain data relevant to this event.

Using Register-ObjectEvent

So you’ve set up FileSystemWatcher and have actions you want to take whenever something happens. For the moment, these two are separate and do not know each other. To make them work together, you must record the actions with the event. PowerShell has a complete cmdlet for this: the Register-ObjectEvent cmdlet. To use Register-ObjectEvent, you need to pass three things to it:

The FileSystemWatcher object
The type of event on which to trigger actions
Actions that you defined previously

If you configured everything the same as above, it will look like this: Register-ObjectEvent $ watcher ‘Event Action’ -Action $ action. ‘Event Action’ can be replaced by any event from the FileSystemWatcher, but that will be a nice demonstration.

Test it

You can now test everything. In this section, you will create a new file in the specified directory, see the event action, then disable and unregister the event.

To create a new file and trigger the event, run the line below in PowerShell. It’s on Ubuntu Linux, but if you’re following on Windows, replace / home / ubuntu / with C: and / with .

New-Item -Path “/ home / ubuntu / WatchThisFolder / newFile” -ItemType File

As soon as you enter this, the event is triggered and the action is triggered.

The file newFile in the path / home / ubuntu / WatchThisFolder / newFile was created on 09/26/2019 20:49:54

It fires whenever you create a new file in this directory or something nested under it, if you have set the IncludeSubdirectories flag. Now that you know that raising the event works, turn it off by running $ watcher.EnableRaisingEvents = $ false, and then try to create a new file. The file must be created, but no event is displayed. This can be very useful if you are debugging and don’t want to trigger anything while working in the file system.

Once you are done, run Get-EventSubscriber | Unregister-Event to unregister the action event. Now, even if the EnableRaisingEvents flag is true and the action occurs, the action will not fire.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.