FileSystemWatcher will not recognize pasted files

Answered FileSystemWatcher will not recognize pasted files

  • Friday, April 27, 2012 8:15 PM
     
      Has Code

    I have an event on 'Created'

            private void fswFileChange_Created(object sender, System.IO.FileSystemEventArgs e)
            {
                System.IO.File.Copy(e.FullPath, "C:\\archive\\" + e.Name);
            }
    

    When I right click on the folder I am watching and click on New Text Document, I see the document being copied to C:\Archive. However when I paste a file from a different folder on to the folder I am watching, it does not copy it to archive. Please assist.

All Replies

  • Saturday, April 28, 2012 4:22 AM
     
     Answered Has Code

    Hi,

    Please try the following code to create a watcher. This will look the directory for the copied files: 

    public void CreateFileWatcher()
    {
    	FileSystemWatcher watcher = new FileSystemWatcher();
    	watcher.Filter = "*.*";
    	watcher.IncludeSubdirectories = true;
    	watcher.Path = ConfigurationManager.AppSettings["Directory"];
    	watcher.EnableRaisingEvents = true;
    	watcher.Created += new FileSystemEventHandler(Watcher_Changed); 	
    }
    public void Watcher_Changed(object sender, FileSystemEventArgs e)
    {
            //Do the operations you want here..
    	string fileName = e.FullPath;
    	Console.Writeline(fileName);
    }


    Always mark the answers if the post answers your question. Prabhu R

  • Monday, April 30, 2012 12:58 PM
     
     

    Thanks. That's pretty much what I have and this does not trigger when I copy a file on to the *watch* directory.

  • Monday, April 30, 2012 1:45 PM
     
     

    Does it throw any exceptions??

    Please double check that the EnableRaisingEvents is set to true and that you have permission to watch the folder. Is it NTFS or Fat32 ?


    With great code, comes great complexity, so keep it simple stupid...

  • Monday, April 30, 2012 1:48 PM
    Moderator
     
     

    File operations don't work quite the way you'd think.  In order to properly handle most file operations you have to handle more than the created event.  In many cases you can get a created event or a set of change events depending completely upon how the application performing the file operation is written.  As Prabhu said, first you should be monitoring the entire directory.  Secondly expand your event handling to include changes and renames (a move operation can be implemented as a rename depending upon what file system is being used).  I suspect after you handle these events you'll see the paste operation work correctly.

    Michael Taylor - 4/30/2012
    http://msmvps.com/blogs/p3net

  • Monday, April 30, 2012 3:12 PM
     
     

    Thank for the inputs.

    Interestingly the paste works on my file server. Initially I had my watch directory set to "C:\\Watch_Directory" on my Win 7 machine. That did not work. But when I tried with my file server \\Servername\directory it worked.

    BUT, if I copy 10 files and paste it onto my watch directory, only the last file to get there copies to  my archive directory. Please let me know what other events should I create and how to handle them.

  • Monday, April 30, 2012 4:08 PM
    Moderator
     
     Answered

    FYI the FSW requires support from the underlying file system.  UNC and remote paths are not supported although sometimes it might work.

    I suspect the problem has nothing to do with FSW and everything to do with your handler.  FSW is implemented as a hook in the Journaling API of the file system.  This is a very low level API.  Your handler is called while the other process is performing the file operation.  Basically, your handler is going to slow down the actual file operation.  Therefore one of the fundamental rules of using FSW is to ensure that your handler does nothing that will take any amount of time.  To do otherwise will: a) slow down the file system and b) potentially cause you to miss file system events.  If you refer to any number of FSW articles (you can google them) you'll find that the defacto standard is to take the event data, package it up to contain the information you need and then push it to a queue or other shared resource that another thread can process at a later time.  The handler should not block for any amount of time.  A separate thread should be responsible for processing the events asynchronously after the fact.  I suspect in your case you're missing the events (assuming you're handling the correct ones which was the original thought).  You can google for articles on how to properly use the FSW as it is not as trivial as it appears.

    Michael Taylor - 4/30/2012
    http://msmvps.com/blogs/p3net