>>OK, so you're saying the error is reporting the destination file is in use by another process before the copy operation completes.
>
>Yes
>
>>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.
>
>No, backup is not an issue.
>
>>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.
>
>Yes, but this is the only location where it happens.
>
>>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.
>
>Interesting, I will have to take notes notes on that.

Another thing to consider - if both source and destination are the same NAS, is there a "native" copy API you could or should be using instead of Windows file system calls?

To show what I mean I'll refer to Novell NetWare file servers of about 25 years ago. If you were copying a file from one server folder to another, you had 2 choices:

1. DOS/Windows Copy command. This caused 2 file transfers:

Source server folder -> across wire to workstation -> across wire back to server destination folder

2. Native NetWare ncopy command. This instructed the server to copy the file from the source to the destination folder, without transferring to the workstation across the network. This could make a huge performance difference with PC/XT workstations and 2.5Mbit/sec ArcNet networking.

If the NAS has a "native" file manipulation API it might be better to use that.

That raises a related question: are the NAS volume(s) mounted as SMB/CIFS or something else such as NFS?