Filesystemwatcher Fails to Access Network Drive

FileSystemWatcher Fails to access network drive

I have projects using the FileSystemWatcher object monitoring UNC paths without any issues.

My guess from looking at your code example may be that you are pointing the watcher at the root share of the server (//servername/) which may not be a valid file system share? I know it returns things like printers, scheduled tasks, etc. in windows explorer.

Try pointing the watcher to a share beneath the root - something like //servername/c$/ would be a good test example if you have remote administrative rights on the server.

FileSystemWatcher.Path Exception for Network Shared Drive

Drive letter mappings are a per-interactive login setting. The exception is telling you the truth, T:\INFORMATION TECHNOLOGY\bu indeed does not exist because for sessions other than your own session (for example the session 0 that the service runs under) the drive T:\ does not get mapped anywhere. The reason it works when you debug is because when you debug you are likely running the service inside your own session instead of inside session 0.

A similar problem happens when you try to access a mapped drive from a program launched from a UAC prompt because the UAC user is considered a "different user".

Possible further reading for potential workarounds "Map a network drive to be used by a service"

FileSystemWatcher to watch UNC path

I just tried this:

var _watcher = new FileSystemWatcher();
_watcher.Path = @"\\10.31.2.221\shared\";
_watcher.NotifyFilter = NotifyFilters.LastWrite | NotifyFilters.FileName;
_watcher.Filter = "*.txt";
_watcher.Created += new FileSystemEventHandler((x, y) =>Console.WriteLine("Created"));
_watcher.Error += new ErrorEventHandler( (x, y) =>Console.WriteLine("Error"));
_watcher.EnableRaisingEvents = true;
Console.ReadKey();

That works without problems, however i replicated your exception just when:

• The running user doesn't have permissions to read the remote folder.
• The remote folder doesn't exist.

Your problem surely is related with permissions, I think that the running user doesn't have the permissions needed.

Another thing that you can try is map the remote folder to one local.

Execute this in the cmd:

NET USE Z: \\server2\Secondary\temp\watch_folder /user:Domain\UserName Password

Then in your code:

_watcher.Path = @"Z:\";

C# FileSystemWatcher watch changes on network drive which is only done by current system

FileSystemWatcher may notify you that something happened, and you might also be able to deduce what happened, but don't count on it. It's a quite limited and unreliable component in my (and others') experience. So if there is any chance of even moderate contention on the target folder I would use some kind of polling solution instead of file watcher.

That said, it won't tell you who did the change. Once you have deduced what has changed, you need to take additional steps for the "who" part. The filesystem stores quite sparse info, you won't find any source machine info. You could try mapping the fileshares that create these changes with different users, as you may deduce the modifying system from that:
Finding the user who modified the shared drive folder files.

If that is not an option, other solutions are much more complicated.

If you have access to the server hosting Z: you could turn on the file audit log for that resource and deduce who the machine was from the event log (event ids 4663 / 5145). The source machine name will be logged in this case. Should be a breeze to enable it if it's a windows server (Directory properties/security/advanced/audit), but reading and synchronizing logs is more complicated.

If none of the solutions above is possible, you may be able to implement a user-space filesystem to proxy your file share, using something like dokan. Source processes would map to your application instead of the fileshare, that way you could raise your own events or just write a detailed audit log to a database or whatever, and then you forward the actual commands to the fileshare. Very expensive and non-trivial solution though. But probably very fun.

When watching a network drive Created is not fired when the file comes from another drive

The Renamed event did the trick.
I am not sure if the drive is already being watched, because i am not the owner of the share. Other Shares on the same drive are firing "Created".

Many thanks

.NetCore - FileSystemWatcher on a network drive, unsafe code Win32 API crash

Just a quick update, because I'm still on the way to fix it.

I created a MS Support issue.
After many try we just succeed to reproduce it. We had to "play" with the network and simulating some "disturbances".
It seems that FileSystemWatcher events didn't been sent as it should be (It's sent by TCP protocol, SMB way).
Our team is still working on finding how it can happen..

MS agreed that this shouldn't crash the FileSystemWatcher in some unsafe code no matter if there was a real network issue.
So, they just made a PR to add some security around it.

I'm still following the PR but it should be fix in .Net 5 and backported in .Net Core 3.1(.9).

Thanks for the help.

FileSystemWatcher on mapped network drive

Well, I have used the FileSystemWatcher to monitor a shared folder that exists on another computer in the network, and here is my experience:

1. You can check the connection via File.Exists or Folder.Exists.
2. The FileSystemWatcher will not throw an exception if the you lose connection to that shared folder. Instead, whenever the connection is lost you will get this error message:
   "The specified network name is no longer available". When you get that error, the FSW will no longer handle any data even if the connection is reestablished, so handle FileSystemWatcher.Error event and if the error is raised, reset EnableRaisingEvents to true again, or reinitialize the FSW

---

Related Topics