I'm not exactly sure what's going on in this script as I can't see what fileparse() is supposed to be doing, but I suspect that whatever it is, $file may not have been closed properly by the time your script is trying to move it. (This may or may not be the script's fault -- please keep reading)

I see that the script used to do a system() call to execute the shell command "move" directly but was revised to use File::Copy. Now, the commented lines have a time stamp suggesting that this problem has been around for a while and I have a feeling that the problem therefore isn't really related to how the move operation is executed at all.

Searching around for a bit, I find that IF the files happen to be on a network share, this has been known to just happen occasionally, because Windows. http://stackoverflow.com/questions/1167942/why-does-perls-filecopy-appear-to-silently-fail (See the bottom answer in particular, it offers a possible solution that may or may not solve your underlying problem.)

Apart from this, I don't know the internals of File::Copy but it's possible that module ends up spawning a shell to execute "move" or perhaps even "copy" followed by "delete" in order to be OS independent. If the number of processes is an actual problem then I suggest trying to do the copying yourself, in pure Perl, by opening a read handle + a write handle and then unlink the original file after you have verified the copy is good. Maybe this would atleast help you zero in on the root cause.