C # - Predict file system events in delete folder

It is more a question of what is the best practice in implementing this.

I have a FileSystemWatcher that should let me know about user changes in files and folders. Subdir is also observed. In the same directory, my program also sometimes changes. I do not want FileSystemWatcher detect events during these program changes.

My first implementation was a list where I can add the expected events. When I receive a file system event, I check the list and ignore it if there is one. It doesn't seem very reliable, but it seems to work.

Now I discovered a real problem:
D: Browse through FileSystemWatcher .
I have two folders: D: \ folder1 \ folder2
Now I want to delete folder1 (with folder2 in it) with my application. So I put D: \ folder1 in my delete list. Then I call something like Directory.Delete(@"D:\folder1", true) . Now I notice that folder1 cannot be deleted (for some reason) due to an exception. I delete the delete entry from my list, but folder2 has already been deleted and I get its FileSystemEvent. Therefore, I get a FileSystem event for D: \ folder1 \ folder2. My program thinks the user has deleted this folder and is doing the wrong thing.

I got some ideas:

1.) delete a folder recursively, deleting each file and each folder independently. With this, I get for each subfolder and write my own entry in the list. I have already implemented it, but very very slowly.

2.) Maybe there is a better way to have smart filters in FileSystemWatcher to make my list obsolete?

3.) Perhaps you can only delete the directory tree, if you can delete everything. Therefore, if this fails, I still have everything, and if not everything is deleted. This seems to be the most elegant solution for me, but I don’t know if it is possible at all?

4.) Is it possible to exclusively block all files and folders using my software? If this is all right, should it be possible to delete everything with a single delete command or something like that?

I am also open to other additional solutions.

Edit 1 to make it clearer:

I want to "see" user actions in a folder. If I will manipulate things from my program here, I do not want to see these events.

In my implementation, I get events for subfolders if the folder is locked and cannot be deleted.

It is not so easy to explain in English, because I am not a native speaker of English;).

Edit 2:

5.) Maybe you can filter all the events from a specific process in FileSystemWatcher ?

+5
c # filesystemwatcher cascading-deletes
source share
3 answers

Ok, here is my solution to the problem:

For delete command only:

I implemented 2 lists, one for deleting files and one for deleting a folder.

Entries in the file list do not have a timeout. If I delete the file, I create a list entry, and if I get the expected delete event, I delete the entry as before.

Folder List Entries

do not have a timeout after creation. I can manually skip them manually after a second using a special method. If I delete the folder, I will add the deleteFolder list entry. Each delete event from this folder or file or subfolder or subfolder file is ignored due to this delete folder entry. After the deletion is complete, I will set a timeout for the deleteFolder entry. If the deletion throws an exception, I do the same. Therefore, I expect to receive all events in a second. Therefore, I ignore all events if the delete command works or not. After that, the deleteFolder list item is deleted.

Limitations: 1. All deleted events must pass one second after deletion. 2. You cannot delete such a folder:
delete folder (completed)
create folder again
wait less than 1 second
delete the folder again (timeout did not finish writing the list of deleted folders)

Hope this helps someone, even if it is very difficult ^^

0
source share

I have been doing exactly something lately; the trick is for your β€œlist” to recognize that where there is a folder name in the list, also discard any events for anything in that folder if it expects a delete event, and removes it only from the forecast list if it itself is a folder.

I should warn you, however, you are likely to run into problems filling the FileSystemWatcher buffer if too many events happen in quick succession; if this happens, it will fire an Error event and not tell you about the whole event. If your prediction list deletes items when it is received, you risk ignoring future events only because the event that you planned to ignore was never received due to a buffer overflow. It can also become very large because items are never removed from the list.

I have yet to find a reliable way to do this, although you can set the maximum size of the FileSystemWatcher buffer to soften it to an extent.

EDIT: Also very important: the events that are returned do it in another thread (unless your handler is on an object that implements ISynchronizeInvoke , such as Control or Form , and you set SynchronizingObject to your Control / Form . This means that you need to be very careful how you maintain your list, given the potential conditions of the race.I am still struggling with this, my code resets the forecast list when an error event is received, but by the time it processes the event, other change events, since the mistake was already for started up and processed, and it discards everything that should not.

+2
source share

Regarding buffer overflows. The best way to solve this problem is to do the work in response to an event in another thread. I do it like this:

 // Queue of changed paths. private readonly Queue<string> mEventQueue = new Queue<string>(); // add this as handler for filesystemwatcher events public void FileSystemEvent(object source, FileSystemEventArgs e) { lock (mEventQueue) { if (!mEventQueue.Contains(e.FullPath)) { mEventQueue.Enqueue(e.FullPath); Monitor.Pulse(mEventQueue); } } } // start this on another thread public void WatchLoop() { string path; while (true) { lock (mEventQueue) { while (mEventQueue.Count == 0) Monitor.Wait(mEventQueue); path = mEventQueue.Dequeue(); if (path == null) break; } // do whatever you want to do } } 

So I will never miss an event

+1
source share

All Articles