filesystemwatcher problem in c#.net - c#

I have a filesystemwatcher event which watches the path. The problem is when a bulk of files are downloaded into the path where the filesystemwatcher watches, filecreated occurs first then filedeleted occurs which causes all the file to get delete and never the filecreated occur again.
I want to know how to control this condition of filesystemwatcher handling events for files which are getting downloading. I want only one event filecreated/filechanged after the file is finished downloading. And not any other events when it is downloading.
How to achieve this?

Why don't you tell what exactly you want to do may be a simple console app scheduled to run every few minutes will solve your problem.

Related

FileSystemWatcher skips Created-events

I have a FileSystemWatcher that checks multiple directories if there are any files created.
((System.ComponentModel.ISupportInitialize)(FileMonitor)).BeginInit();
FileMonitor.EnableRaisingEvents = true;
FileMonitor.Created += new FileSystemEventHandler(FileMonitor_Created);
FileMonitor.Path = Path.ToString();
FileMonitor.IncludeSubdirectories = true;
FileMonitor.NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.LastWrite | NotifyFilters.FileName | NotifyFilters.DirectoryName | NotifyFilters.Attributes;
((System.ComponentModel.ISupportInitialize)(FileMonitor)).EndInit();
For some reason the FileMonitor_Created event is not always fired when running the application, even though it should. It feels random...
However, if I put a breakpoint at the FileMonitor_Created method, it works perfectly: The event fires everytime it should, if the breakpoint is set.
I've tried setting an InterBufferSize for the FileMonitor, but that had no effect.
Update
I added the Changed event to the Filemonitor and gave it the same handler as for the Created event. Somehow it works now, although the file is actually created, not changed.
I'm still curious why it always worked 'the old way' when setting a breakpoint.
How many changes are you making?
The Windows operating system notifies your component of file changes
in a buffer created by the FileSystemWatcher. If there are many
changes in a short time, the buffer can overflow. This causes the
component to lose track of changes in the directory, and it will only
provide blanket notification. Increasing the size of the buffer with
the InternalBufferSize property is expensive, as it comes from
non-paged memory that cannot be swapped out to disk, so keep the
buffer as small yet large enough to not miss any file change events.
To avoid a buffer overflow, use the NotifyFilter and
IncludeSubdirectories properties so you can filter out unwanted change
notifications.
Taken from MSDN
If you have a breakpoint its working, but if you don't, its not?
Are you sure that there's not something in your event handler? Like there's an exception occurring which makes the program 'feel' like its not doing anything? Can you post the code in the handler?
Separate your business logic from the FileMonitor_Created event.
In the event you should store the event parameters and return.
E.g. store the event parameters in a queue, then process these events async.
FileMonitor.Created fires when the file created and not replaced with the previous file with the same created date time.
Scenario 1) Copy paste and over right the same abc.txt File in input folder without any changes to the file creation date or file content- - File watcher doesn't recognize the file.
Scenario 2) Copy paste and over right the same file in input folder with new created date File watcher recognizes the file
So the created event works with the second scenario, it might not be your situation but looks hidden behavior for my first view.
When event is raised, file processing might take some time. During that time another file might be created and event handler will not handle the second file because it is still handling the first file. Therefore, second file is missed by FileSystemWatcher.
Solution is to separate file detection form file processing into two threads and connect then by a queue. It is producer-consumer queue.
File detection should be as short as can be. It should only detect a file, enqueue its file name in queue that file processing thread can process and close so another file can be detected. File processing thread can dequeue file name and take as much time as it needs to process it.
I explained this in detail with the code in this article: FileSystemWatcher skips some events

Are there any open/delete/copy file events that can be caught before the action starts?

How can I find out that user tries to open a file?
I found some events in Windows API but they just notice that file was opened.
Using FileSystemWatcher you can track various changes on the file, see the filters NotifyFilters-
http://channel9.msdn.com/Forums/TechOff/246319-FileSystemWatcher-for-opening-files
FileSystemWatcher triggers for filestream open
You can also try the below link to know how can your create and use FileSystemWatcher component to monitor the changes made to the file system.
http://www.mstecharticles.com/2012/09/c-monitor-file-system-using.html

File listener - how can I know when the file is accessable?

I have a file listener on a win service.
I raise event on file created/
some time I get execption "cannot access to the file because it being used by another program"
do someone has an idea?
You could use FileSystemWatcher to get notification on the file system but you should be more explicit if possible.
More info on it here:
http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx
My suggestion, even when using a FileSystem watcher, is simply to do a Thread.Sleep(1000) after the FileCreated (or whichever event you are watching) has fired, so that you are 100% sure that the previous process has done with it. I have had a similar experience when using FileSystem watchers, and pausing for a while before trying the access the file fixed the issue.

How can i get user who deleted file?

I need to know which user deleted file in filesystem from c# code.
Only one idea is to use audit, but it seem to be very slow...
You can use the FileSystemWatcher.Deleted event to capture deletes happening on the filesystem.
Depending on the application, you may at that point also be able to find out what user caused this event to occur (it is not part of FileSystemEventArgs).
I don't know if this can be retrieved from the filsystem, but one possible way is to use av FileSystemWatcher object to trigger an event on Deleted. The downside is that you need to have the watcher application running all the time. One upside is that you can monitor just a spesific folder if that's feasible.

events in a file system watcher

when i use a file system watcher changed event for a notepad it occurs once,but the event occurs twice for a word pad,please give me the reason.i launch using explorer
A bit Briefly,
I have a file named "xxx.log" it contains some strings,i wrote a filesystemwatcher which will watch this file for size(notifyfilter - size) changed.whenever
i opened the file with notepad the changedevent occurs once,whenevr i do it with wordpad
the event occurs twice what is the reason. i open files using explorer.exe.
how to handle this problem.i need the event once only,is there any way
I think that notepad has no lock/backup file handling. Thus it writes only once to the file - Word and Wordpad work with some temporary files for backup and locking purposes and for that reason they might write twice.
The best way to understand this is to use process monitor from sysinternals. This will show you exactly what is going on.

Categories