>>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.

OK, so you're saying the error is reporting the destination file is in use by another process before the copy operation completes.

>>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.

Yes, it might. If there was a backup running while you copy a file into a folder currently being backed up there could well be occasional contention. You could ask the netadmin if there were backup jobs running at the times you got the errors, so you would know if they could be the cause.

These days most Windows backups use Shadow Copy (aka VSS) so processes can continue to use a volume while it's being backed up. Your NAS probably doesn't run Windows so it won't have Shadow Copy, but it might have a similar technology. If it doesn't you could definitely get contention.

>>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.

I wouldn't be so sure... occasional or rare problems like this is exactly what you can get with AV that's either buggy or can't keep up with high I/O levels.

>>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.

Do you know if the NAS has deduplication (dedupe)? If so, that would come into play if both the source and destination were the same NAS. Again, my understanding is systems that support it work well with basic file operations but it could be another complication.