• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 260
  • Last Modified:

FileSystemWatcher behavior


I wonder if anyone out there can confirm and explain two of my observations about FileSystemWatcher:

a) if I have a process that is continuously writing to a file for some period of time, it doesn't report an event until the process is done, then it will report a change.
b) it seems to miss file deletes if I delete it from a DOS window, but it will catch the delete if I delete it from Windows Explorer

Thanks...
0
riceman0
Asked:
riceman0
  • 6
  • 5
1 Solution
 
riceman0Author Commented:

Addendum: it is because of these two facts that I have changed my watcher mechanism to a timer-based function that continuously checks the file size.  Pretty inelegant, eh?
0
 
jrschererCEOCommented:
Hi riceman0
What NotifyFilter do you use?
try  FileSystemWatcher1.NotifyFilter = NotifyFilters.LastWrite
Jack.net
0
 
jrschererCEOCommented:
Oh, I forgot,
Yes, I made the same experience. Changes made in a Dos window (CMD) will not trigger the File System Watcher.
Jack.net
0
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
riceman0Author Commented:

I've tried a variety of filters, similar results.  Do you know if it's supposed to catch changes by other processes/apps?  Or just by the user through the windows shell?  MSDN isn't entirely clear on that...
0
 
riceman0Author Commented:

And... changes made in Notepad DO trigger the FileSystemWatcher... what's the difference?  
0
 
jrschererCEOCommented:
I do a lot of inter-process communication using the file system watcher. It works between processes / applications. It also works if the file is altered by a service.
Jack.net
0
 
riceman0Author Commented:

Any idea why not the DOS window then?  It's just another process, I would think.

Also, seen anything similar to my observation (a)?
0
 
jrschererCEOCommented:
a) I found some missing event reporting using the Dos (CMD) window. But I did not follow up on this, since it was not an operational issue.

b) Question: do you close the write process between write statements? It will only report a write event if the write process closes. You can't access a file anyhow as long as the write process is not closed and the file is open for write by your porcess.
0
 
riceman0Author Commented:

The other process keeps it open and writes to it every cycle until it is done with it.  Actually I've found I can access it (for reading) while it is opened for writing by the other process, if I open it with a shared flag as follows:

Dim fs As New FileStream(FilePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite)
0
 
jrschererCEOCommented:
Yes, you can do this with FileShare.ReadWrite, but you have to be aware that you may read incomplete information.

If you keep the file open between writes, the FileSystemWatcher can not be used to check porgress of the write process. Then your file-size method is probably the best alternative.
Jack.net
0
 
riceman0Author Commented:

Thanks.  You've got at least a share of the points... I'll keep this open a bit to see if anyone has an insight as to why a delete from the DOS window doesn't (and therefore which other programs might not) trigger the FileSystemWatcher...
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now