つまりFinder側の問題ということなのか…そうでもないのか？
自分の閉鎖環境でやってる時は気が付かなかったのですが、お勤めに出ている先で頻繁に起きるので閉鎖環境でテストしてみました。
（久々にwiresharkを新しいのに入れ替えたら、Xアプリだったのがネイティブになっててちょっとびっくり。）
起きる環境
サーバ osxserver 10.6, netatalk2.1.5
お勤め先は非公開なので解りませんが、windowsとかnetatalkではないとのことなので、osxserverでしょう。たぶん。
クライアント MacOS10.11.6
お勤め先は社外秘なので、最新ではないとだけ。
起きる現象
afpサーバ上の同一ボリューム内の異なるフォルダからフォルダへファイルをコピーしようとすると-43エラーで止まる。
よくわからない
パケットキャプチャを読むと、Finderで同じサーバ上のファイルを別のディレクトリにコピーする時は、大雑把にこんな手順のようです。
掴んだファイルの情報を得る。
ドロップ先に掴んだファイルと同名ファイルがあるかどうか尋ねる。
同名ファイルがないよって答えが来たら、ゼロバイトのファイルを作ってくれって要求する（Finderで見えるグレーのファイルはサーバ上にゼロバイトで実際に作られる）
コピー先に作ったゼロバイトのファイルを消してから、コピーを要求する。
コピーされる。
コピーしたよって返事が来たら、コピー先のファイルがあるかどうか尋ねる。
あるよって答えが来たらおしまい。
みたいな感じです。
この間、ファイルがあるかどうかを確認してるので、毎度毎度、それこそ数十ミリ秒に一回くらいobject not foundが返ってくるので、見つからない項目がどうたらは四六時中起こっているわけで、それを捕まえて見つからないと言っているわけでもなさそう。
netatalkにもOSXserverにもエラーログは残らないので、サーバ側のエラーというわけでもなさそう。
相手がnetatalkでもOSXServerでも同じ挙動なので、やっぱりFinderが誤認してるのか？ netatalkはOSXServerと同じ動作を目指してる(?)のでOSXServerと同じ問題を抱えてるのか？
同一サーバでも別のボリュームだと、copyじゃなくて、readとwriteの繰り返し（クライアントを経由する）なので、動作が違うから問題ないのでしょう。
どうも、copyコマンドの扱いに問題がありそうな気がするところまでしかたどり着けなかった…。
