Firstly, ratsandwich was saying that we should use a different finder application (e.g. xfile etc) or a command line alternative (I was using cp in Terminal before, but I'm going to try xfile now).
Secondly, here is what I think is happening. Some people, like me, can't stand the notion of file indexing because the computer uses CPU cycles at its own discretion. I really don't like that, so I turn off indexing with mdutil (a built-in command in Terminal). And here is the consequence of that: when I attempt to copy one small file that already exists to my network drive, it prepares to copy for perhaps 5 minutes before it finally prompts me that it already exists and asks if I want to replace it.
Contrary to other answers I've seen in this forum or others, I don't believe it is checking for space or doing anything necessary -- I presume it must be building an index with/for unnecessary information. Now, to do/check things, yes a simple index is needed, but that should not take long, unless it is implemented badly, or it should be deferred until when it is strictly needed. If it was doing something necessary for the protocol then alternative finder applications would have the same problem, but they clearly don't.
Some of the glib and asanine responses from people who haven't experienced the problem are because they put up with indexing, so that if they do experience an indexing delay it is minimal compared to what I experience.
So I hope this theory of mine about my uncommon configuration (indexing off) explains why this problem hasn't been fixed. Nobody at Apple has bothered to reproduce it to get to the root cause and make the fix. Or provide an option to avoid the problem. It should be easy to do. In the meantime, I will use xfile.
