C # FileSystemWatcher Serious Problem?

I implemented FileSystemWatcher for a folder that is on a NetworkStorage device (without OS).

There are two machines in the script: machine A and machine B. my application has two buttons in my form Button1 and Button2. I wrote code to rename the Test.txt file.

Button1: renaming the file Test.txt to Test007.txt and Button2: renaming the file Test007.txt to Test.txt

And let me run the tis exe file from A and B at the same time. Then I can rename the file by pressing Button1 from Machine A and now if I try to rename the file from another computer B, it reports an error

"System.ComponentModel.Win32Exception: The specified server cannot complete the requested operation"

Does anyone have an idea about this ... please help us find a solution. We have rights to the folder.

Note: The code also works for the local folder, so the code is excellent. It just does not work for NetworkStoreDevice.

+2
source share
4 answers

We created a product for a company where a Windows service running on a server monitored a folder and when the files were added to this folder, the files were read, processed (in this case, a barcode layout was created and printed on a barcode printer), and then deleted.

Everything worked perfectly for a number of clients with fairly good performance, until we met a client where he worked only occasionally. Especially there were problems when several files were added to the folder at once.

The problem was that the folder we were looking at was shared on the samba file system, and FileSystemWatcher did not work reliably with respect to the samba file system (Google for "FileSystemwatcher samba"). Since you're talking about a โ€œNetworkStorage device,โ€ I assume you mean it's a NAS, and NASs often use Linux / Unix under the hoods and share using samba.

Our solution was to add a feature to our software so that it could be configured to use polling when needed.

+5
source

FileSystemWatcher relies on the operating system to enhance the event. If there is no OS on the storage device, there is no OS to raise the level of events.

Note that some factors can affect which file system change events are raised, as described in the following:

General file system actions can lead to several events. For example, when a file moves from one directory to another, several OnChanged events and some OnCreated and OnDeleted events can be raised. Moving a file is a complex operation consisting of several simple operations, so several events occur. Similarly, some applications (such as antivirus software) may trigger additional file system events that are detected by FileSystemWatcher.

FileSystemWatcher can browse drives until they are switched or deleted. FileSystemWatcher does not generate events for CDs or DVDs because timestamps and properties cannot be changed. Remote computers must have one of the necessary platforms installed for the component to work properly.

If multiple FileSystemWatcher objects are viewing the same UNC path in Windows XP before Service Pack 1 (SP1) or Windows 2000 Service Pack 2 (SP2) or earlier, then only one of the objects fires an event. On computers running Windows XP Service Pack 1 (SP1) and later, Windows 2000 SP3 or later, or Windows Server 2003, all FileSystemWatcher objects will raise the corresponding events.

Setting the Filter property does not reduce what is included in the buffer.

Please note that FileSystemWatcher does not cause an error event when the event is skipped or when the buffer size is exceeded due to dependencies with the Windows operating system. To not skip events, follow these guidelines:

Increasing the buffer size using the InternalBufferSize property can prevent the absence of file system change events.

Avoid viewing files with long file names. Consider renaming using shorter names.

Keep your event handling code as short as possible.

Source: MSDN Library Link: FileSystemWatcher Class

+3
source

FileSystemWatcher versus polling to view file changes

See the first answer. File system watchers are not reliable, especially. through the network.

It seems that the problem is not related to your problem, since you seem to be getting events, maybe this is a time problem?

+1
source

Use a combination of FileSystemWatcher and polling

FileSystemWatcher will work in 90% of cases, but every time every 6 minutes add a poll to catch anything that might be missing ...

The value of x depends on how you need "realtime"

0
source

All Articles