title: .NET 4.5 File.Copy ok, but file does not exist
body: <p>strange behaviour in our production environment, these days.
  I have the following:</p>
  
  <pre><code>try {
      var sourcePath = ... // my source path
      var destinationPath = ... // guess what? You're right, my destination path
  
      File.Copy(sourcePath, destinationPath);
      Log.Debug(string.Format("Image {0} copied successfully", imagename));
  }
  catch(Exception e) {
      // exception handling
  }
  </code></pre>
  
  <p>Both source and destination path are on a network share, a folder on an other (virtual) machine with a large number of files (> 500k).
  From the last 2 days, the code above runs, logs the last line (the one stating that image  have been copied), but if I check in the destination folder, the supposed destination file does not exist.</p>
  
  <p>I thought that for any I/O error File.Copy would raise an exception, so this thing is driving me mad.
  Please note that other code parts that write files in that folder are working correctly. Also, note that all files names are unique (business code not included for brevity is making sure of that), and I think an exception would be thrown or the file would be at least overwritten, in that case.</p>
  
  <p>Has anyone faced the same problem? Possible causes? Any solution?</p>
  
  <p><strong>EDIT 2016-07-01 15:12 (GMT+0200)</strong></p>
  
  <p>Ok, folks, apparently files aren't being deleted at all... simply for apparently no reason at all, after they are copied they're left open in read+write mode from the client connected user.
  I found this trying running the reader application on my computer, in debug mode, and trying to open one of the files i knew that were copied recently.
  I got an exception stating that the file was opened by someone else, and that seemed weird to me.
  Opening Computer Management in the remote server (the one which stores the files), then going to Shared Folders > Open Files, I found that the file was left open in read+write mode from the impersonated user that the web application that copies the files is impersonating to do that job.
  Also a whole bunch of other files where in the same conditions, and many others where open in read mode.
  I found also in Shared Folders > Sessions, an astronomical long list of session of the impersonated user, all with long idle time.
  Since impersonation is used only to copy the files, and then is disposed, I shouldn't expect that, right?</p>
  
  <p>I think maybe there is a problem in the way we impersonate the user during file copy, linked to the large number of files in the destination folder.
  I'll check that.</p>
  
  <p><strong>END EDIT</strong></p>
  
  <p>Thanks,</p>
  
  <p>Claudio Valerio</p>