How to reliably know when large file is done copying?

Is there anyway to reliably know when a large file has completely finished copying to a particular folder? For example, Computer1 copies a large file to Server1\Share1. On Server1\Share1, I want to do something AFTER the file is done copying, without Computer1 intervention.

It seems that the .NET FileWatcher does not have any way of doing this, as there is only a file create event, but not a file done copying event.

Is this something that will have to be done via Win32? Any help, points, or sample code would be most appreciated.

hmm, MsgBox("Copying Finished!")

I'm sure that was a joke, right?

Just in case it wasn't a joke, maybe I should further clarify what I'm talking about. The SERVER needs to do something in response to the large file having been completely copied. Computer1 does nothing but copies the file. So initiating a MsgBox or anything else for that matter) on Computer1 would be completely useless in this scenario, as it is the SERVER that needs to do something, without any intervention or knowledge by Computer1.

Random answer there ^!

I used this method for FTP transfers. Test the file and keep reading the file size say every 5 seconds until the file size stops changing. Once the file size is stable, you can attempt to open the file with no shared access, which will fail if the file is still in use by another process. If the program that creates the file keeps re-opening the file to append to it, the second check is useless, but if you can ensure that the file is being written to constantly the first check will work well enough on its own. There is no fully reliable way unless you are told by the controller (whoever sends/creates the file), but this has worked very well over the years.

Could you use Try-Catch on file open?

Ok, interesting solution. I think in most situations, the user will be copying a file via Windows Explorer so there should be no weird behavior, unless they decide to use their own client app that does some strange processing to copy the file. So I think your solution should work in 99% of the cases. Have you ever encountered particular situations where this method fails?

Quote:

---

Originally Posted by dbasnett

Could you use Try-Catch on file open?

---

So use a FileWatcher, and when a new file is detected, try to open it say every 5 seconds or so until it no longer fails, at which time it is assumed that the file has stopped copying? I guess this is similar to the other suggestion. I will give these a try. Thanks guys!

Only as mentioned. Certain log files (ie system IIS logs!) write out more space then they need, to save increasing the file size each time, and then "insert" data into this empty space. The file size does not change, but the file is always locked so having 2 checks seems to work on everything I have tried.

I believe windows creates the file as zero bytes and then when it finishes writing, the file size "fixes" itself to the correct size. I have to deal with files being ftp'ed, copied, log files, system files etc so both checks were important.

Edit, take that back, in Vista, my file size is correct at the start of the copy with a last edit date of now. When the copy was finished the last edit date was fixed with the source last edit date :).

Good deal, thanks again!

lol, I'm actually with the second guy, check the file size periodically, that's what I do on a different project which does a similar thing. Regarding the filesize, depends on the way you're copying the file, like just simply copying it (thus as you say, the file size is actually the full file size, even if the file hasn't been transferred completely), or you write it with chunks of a byte at a time, which would actuall tell the true copied file size.