This topic has not yet been rated - Rate this topic

FileSystemWatcher.Filter Property

Updated: December 2010

Gets or sets the filter string used to determine what files are monitored in a directory.

Namespace:  System.IO
Assembly:  System (in System.dll)
[SettingsBindableAttribute(true)]
[IODescriptionAttribute("FSW_Filter")]
[TypeConverterAttribute("System.Diagnostics.Design.StringValueConverter, System.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")]
public string Filter { get; set; }

Property Value

Type: System.String
The filter string. The default is "*.*" (Watches all files.)

To watch changes in all files, set the Filter property to an empty string (""). To watch a specific file, set the Filter property to the file name. For example, to watch for changes in the file MyDoc.txt, set the Filter property to "MyDoc.txt". You can also watch for changes in a certain type of file. For example, to watch for changes in any text files, set the Filter property to "*.txt". Use of multiple filters such as "*.txt|*.doc" is not supported.

The Filter property can be changed after the FileSystemWatcher object has started receiving events.

For more information about filtering out unwanted notifications, see the NotifyFilter, IncludeSubdirectories, and InternalBufferSize properties.

Filter accepts wildcards for matching files, as shown in the following examples.

Filter string

Watches the following files

*.*

All files (default). An empty string ("") also watches all files.

*.txt

All files with a "txt" extension.

*recipe.doc

All files ending in "recipe" with a "doc" extension.

win*.xml

All files beginning with "win" with an "xml" extension.

Sales*200?.xls

Matches the following:

Sales July 2001.xlsSales Aug 2002.xlsSales March 2004.xls

but does not match:

Sales Nov 1999.xls

MyReport.Doc

Watches only MyReport.doc

The following example creates a FileSystemWatcher to watch the directory specified at run time. The component is set to watch for changes in LastWrite and LastAccess time, the creation, deletion, or renaming of text files in the directory. If a file is changed, created, or deleted, the path to the file prints to the console. When a file is renamed, the old and new paths print to the console.

Use the System.Diagnostics and System.IO namespaces for this example.


using System;
using System.IO;
using System.Security.Permissions;

public class Watcher
{

    public static void Main()
    {
    Run();

    }

    [PermissionSet(SecurityAction.Demand, Name="FullTrust")]
    public static void Run()
    {
        string[] args = System.Environment.GetCommandLineArgs();

        // If a directory is not specified, exit program.
        if(args.Length != 2)
        {
            // Display the proper way to call the program.
            Console.WriteLine("Usage: Watcher.exe (directory)");
            return;
        }

        // Create a new FileSystemWatcher and set its properties.
        FileSystemWatcher watcher = new FileSystemWatcher();
        watcher.Path = args[1];
        /* Watch for changes in LastAccess and LastWrite times, and
           the renaming of files or directories. */
        watcher.NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.LastWrite
           | NotifyFilters.FileName | NotifyFilters.DirectoryName;
        // Only watch text files.
        watcher.Filter = "*.txt";

        // Add event handlers.
        watcher.Changed += new FileSystemEventHandler(OnChanged);
        watcher.Created += new FileSystemEventHandler(OnChanged);
        watcher.Deleted += new FileSystemEventHandler(OnChanged);
        watcher.Renamed += new RenamedEventHandler(OnRenamed);

        // Begin watching.
        watcher.EnableRaisingEvents = true;

        // Wait for the user to quit the program.
        Console.WriteLine("Press \'q\' to quit the sample.");
        while(Console.Read()!='q');
    }

    // Define the event handlers.
    private static void OnChanged(object source, FileSystemEventArgs e)
    {
        // Specify what is done when a file is changed, created, or deleted.
       Console.WriteLine("File: " +  e.FullPath + " " + e.ChangeType);
    }

    private static void OnRenamed(object source, RenamedEventArgs e)
    {
        // Specify what is done when a file is renamed.
        Console.WriteLine("File: {0} renamed to {1}", e.OldFullPath, e.FullPath);
    }
}



.NET Framework

Supported in: 4, 3.5, 3.0, 2.0, 1.1, 1.0

.NET Framework Client Profile

Supported in: 4, 3.5 SP1

Windows 7, Windows Vista SP1 or later, Windows XP SP3, Windows XP SP2 x64 Edition, Windows Server 2008 (Server Core not supported), Windows Server 2008 R2 (Server Core supported with SP1 or later), Windows Server 2003 SP2

The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.

Date

History

Reason

December 2010

Clarified use of buffer.

Information enhancement.

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Enhancement request or example code for multiple filters
Myself and a fair few others out there have been looking for a way to implement multiple filters (same target dir) without the overhead of one to one hooks or using regEx on all files. Something along the lines of the "*.txt|*.csv|*.dat" filter in file dialogs would seem appropriate.
It would also be useful insome cases to know which filter has been fired,especially when a common event handler is used. Perhaps another property of the FileSystemEventArgs could be used.
Regards

D.
RE: Clarifying
I believe the change was made to remove confusion around the Filter.  If you look at the older documentation regards to Filter, and FileSystemWatcher class they both say "does not limit/decrease what goes into the buffer" but then you look at the Error event and it says "To avoid a buffer overflow, use ... Filter, ..." 

To me it reads that Filter does not prevent overflow, while we should use Filter to prevent it.
Missing clarifying statement
Every developer who ever used the synchronous method FileSystemWatcher.WaitForChanged() knows that the method "does not always work" when FileSystemWatcher.Filter is set to a non-empty value and FileSystemWatcher.EnableRaisingEvents is not set to true.

Although EnableRaisingEvents *is* subsequently set to true by the Framework's code, also does an internal flag runOnce, which eventually leads to WaitForChanged() waiting only for the first change notification (which can be every change notification from the specified directory and not only a notification regarding a file that matches the FileSystemWatcher.Filter). Because of runOnce flag getting internally set, the FileSystemWatcher "stops listening" after the first, potentially unwanted notification has been received.

Other versions of this documentation were very helpful in mentioning that:

"The Filter applies to change notifications AFTER they have gone through the buffer and DOES NOT LIMIT what goes into the buffer. "

Source: http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.filter(v=VS.80).aspx

What happened to this clarifying statement?