>1. I'm not sure you've actually answered Viv's question about being sure that the copy operation has actually started before you get the error message. Most OSs will retry file operations for a while before timing out. Are you certain you're not hitting the problem immediately but not seeing it for X seconds while the OS retries?

If the file does not exist in the destination and the copy is in progress, combined with an error targeting on the destination, then it would unlikely that it would have happened before the file started to get copied. But, again, I am still searching as to know if the .NET copy file functionality does in fact apply a lock on the file until it has finished copied it.

>2. You may not think other processes could access your file but there could be processes such as scheduled backups, background defrag etc.

If that is the case, it would mean even the .TMP approach would fall into that error after we deploy that fix.

>3. Is antivirus real-time scanning in play on the source computer, destination computer or the one throwing the error you're seeing? Is it always different files that cause the error? Are they particularly large, or do they have an extension (e.g. .EXE) that might make AV pay them special attention?

It is just at one location. With millions of files being copied on a weekly basis, I would probably eliminate that possibility from the loop.

>4. Is the source file on a NAS? My understanding is NAS support for simple file operations such as copying is good but if all else fails it might be worth investigating

The source is from a NAS so is the destination, from the same NAS BTW.