File Copy Issues and Solutions When Using FileSystemWatcher for Directory Monitoring

Nov 23, 2025 · Programming · 8 views · 7.8

Keywords: FileSystemWatcher | NotifyFilters | File Monitoring | C# Programming | Windows Forms

Abstract: This article provides an in-depth analysis of unexpected program termination issues when using FileSystemWatcher for directory monitoring in Windows Forms applications. By examining the impact of NotifyFilters configuration on file copy operations, it reveals the critical relationship between file locking states and event triggering timing. The paper details how to resolve race conditions in file copying processes through optimized NotifyFilters settings, ensuring continuous and stable directory monitoring. Complete code implementations and best practice recommendations are provided to help developers avoid common file system monitoring pitfalls.

Problem Background and Phenomenon Analysis

In Windows Forms application development, using the FileSystemWatcher component to monitor directory changes is a common requirement. Developers typically expect the program to run continuously and respond in real-time to file changes in the directory. However, in practical applications, unexpected program termination often occurs, even without obvious error messages.

From the problem description, it's evident that after copying files to the target directory, when new files are added, the program terminates without warning. Sometimes two files can be successfully copied, but the program terminates when the third file is added. This phenomenon indicates the presence of resource competition or event handling exceptions.

Core Problem Diagnosis

Analysis of the original code reveals that the problem primarily stems from improper NotifyFilters configuration. The original code set multiple notification filters:

NotifyFilters.LastAccess | NotifyFilters.LastWrite | NotifyFilters.FileName | NotifyFilters.DirectoryName

This configuration causes FileSystemWatcher to trigger Changed events multiple times during different stages of file operations. When a file is being copied or written, the program attempts to access the file, but since the file remains locked, the operation fails, eventually leading to abnormal program termination.

Solution Implementation

Through practical verification, the most effective solution is to simplify the NotifyFilters configuration, retaining only the LastWrite filter:

private void watch() { FileSystemWatcher watcher = new FileSystemWatcher(); watcher.Path = path; watcher.NotifyFilter = NotifyFilters.LastWrite; watcher.Filter = "*.*"; watcher.Changed += new FileSystemEventHandler(OnChanged); watcher.EnableRaisingEvents = true; }

This configuration ensures that FileSystemWatcher triggers events only when file writing is complete, avoiding attempts to access locked files during file operations.

Technical Principle Deep Dive

FileSystemWatcher operates based on operating system-level file system notification mechanisms. When multiple NotifyFilters are set, the system triggers events when any filter condition is met. This can lead to the following issues:

By using only the LastWrite filter, events are triggered after file write operations complete, when files are typically unlocked and safe for copy operations.

Additional Optimization Recommendations

Beyond NotifyFilters optimization, the following measures can further enhance program stability:

Practical Application Scenarios

This optimization approach applies to various scenarios requiring real-time file monitoring:

Through proper NotifyFilters configuration, stable and reliable file monitoring applications can be built to meet enterprise-level application requirements.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.