title: How to tell a file is *completely* written
body: <p>I am familiar with the FileSystemWatcher class, and have tested using this, alternatively I have tested using a fast loop and doing a directory listing of files of type in a directory. In this particular case they are zip compressed SDF files, I need to decompress, open, and query.</p>
  
  <p>The problem is that when a large file is put in a directory, sometimes that takes time, such as it being downloaded, or copied from a network location, etc...</p>
  
  <p>When the FileSystemWatcher raises an OnChange event, I have a handle to the ChangeType and on these types of operations the Create is immediate, while the file is still not completely copied to the location.</p>
  
  <p>Likewise using the loop, I see a file is there, before the <em>whole</em> file is there.</p>
  
  <p>The FileSystemWatcher raises several change events, one after create, and then one or more during the copy, nothing that says <em>This file is now complete</em></p>
  
  <p>So if I am expecting files of a type, to be placed in a directory ultimately to read and processed, with no knowledge of their transport mechanism, and no knowledge of their final size...</p>
  
  <p>How do I know when the file is ready to actually <em>be</em> processed other than with using error control as a workflow control (albeit the error control is there anyway as it should be)? This just seems like a bad way to have to handle this, as sometimes the error control may actually be representing a legitimate issue, sometimes it may just be that the file is not completely written, and I do not see any real safe way to differentiate.</p>
  
  <p>I despise anticipated error, but realize that is has its place like sockets, nothing guarantees a check for open does not change before an attempt to read/write. But I do avoid it at all costs.</p>
  
  <p>This particular one troubles me mostly because of the ambiguity of the message that will be produced. There is a conflict queue for files that legitimately error because they did not come across entirely or are otherwise corrupt, I do not want otherwise good files going there.  Getting more granular to detect this specific case will be almost impossible.</p>
  
  <p>edit:
  I know I can do this... And I have read the other SA articles concerning others doing the same thing. (And I know this method is both crude and blocking, it is just an example.)</p>
  
  <pre><code>private static void OnChanged(object source, FileSystemEventArgs e)
  {
      if (e.ChangeType == WatcherChangeTypes.Created)
      {
          bool ready = false;
          while (!ready)
          {
              try
              {
                  using (FileStream fs = new FileStream(e.FullPath, FileMode.Open))
                  {
                      Console.WriteLine(String.Format("{0} - {1}", e.FullPath, fs.Length));
                  }
                  ready = true;
              }
              catch (IOException)
              {
                  ready = false;
              }
          }
      }
  }
  </code></pre>
  
  <p>What I am trying to find out is this definitively the only way, is there no other component, or some hook to the file system that will actually do this with a proper event?</p>