コピーが止まる問題をtcpdumpで見て何とか探すとかいうのは素人には無理すぎるw
finderで何かをコピーするってことは、finderのwindowをいくつか開いているわけで、こうしてあると、afpは接続持続のためのnoopを発行してみたり、window内のファイルリストをリアルタイムに近い形で更新するために、何もしなくても10秒に一度くらいファイルリストを問い合わせしてるし、コピー操作以外の通信が多すぎて、しかも、同じコマンドを使ったりしてるので何が何だか分からないw
もしかして、ファイルリストの更新のコマンドを発行するタイミングで、コピー先にあったはずのゼロバイトの一時ファイルがなくなってたりすると誤認識したりするのだろうか……。
それにしても、wireshark様のお蔭でtcpdumpのコマンドを覚えなくてもなんとかなるのは助かる。
自分の閉鎖環境でやってる時は気が付かなかったのですが、お勤めに出ている先で頻繁に起きるので閉鎖環境でテストしてみました。
（久々に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コマンドの扱いに問題がありそうな気がするところまでしかたどり着けなかった…。
久し振りにcssをlintしようかと思ったら、以前の環境で使っていたcsslinterが動かないので、この機会にstylelintに変えてみました。
で、npmで入れて、.stylelintrcを作って、ターミナルで使うとvimのsyntastic経由でゆるゆる動きます。
メインのmacvimでさてやるか。と思ったらうんともすんとも言わない。
.vimrcに
let g:syntastic_css_checkers = [‘stylelint’]
って書くだけで動くはずなのに。っていうか、ターミナルでは動いてるし……。
ここは~/.zshrc問題であろうと、/etc/zshrcをzprofileに変更（なんかのうpデートのときに再作成されたらしく、あった）。npmのPATHも書いたし、動けw
と思ったら、動かない。
これはもう、pyenvのときと同じく、.vimrcに直ガキするしかなかろうと。
call IncludePath(expand(“~/.nodebrew/current/bin”))
を書いたら、漸く動いた。
安定して動いてる期間が長かったので、保存して左に>>が出なかったら問題なし。っていう意識しかなくなっていたので、何を使っていたかすら忘れてしまいましたが、以前のcsslinterよりだいぶノロノロした感じ。機能は立派なので、便利は便利。
添付されてくる旧型フォントはたいてい壊れています。
昔買って、使えるからまだ使ってる感じの欧文フォントの大半がこの状態で送られてきます。大半は言いすぎでした。全部です。
他OSで解凍した時に出て来るクソゴミの__MACOSXフォルダの中身こそが旧型フォントの本体です。標準装備のzip以外で圧縮するとゴミとして無視されてしまい、何も無いゼロバイトの謎ファイルだけが添付されます。
OSXのFinderで右クリックして出て来る”を圧縮”で圧縮すれば、OSX標準装備のzipで圧縮されるので、ゴミの中の本体が活かせます。
ゴミがうざいから標準zipはヤメロと言われる人も多いでしょうが、相手がmac確定の時は迷わず標準zipで圧縮すべきです。
うち、windowsだからゴミやめてwというところでは、どのみちmacの旧型フォントは使えないので添付しても無駄で、アウトライン化が必須でしょう。勿論直してもらえませんw
ここらへんは色々めんどくさくて、たとえば、md5sumとかsha1sumとかを取ると、本体しか比較しないようで、リソースフォークを取っ払ったファイルと元ファイルが一致してしまいます。
旧型フォントだと、生きているファイルと、圧縮ソフトに殺されたゼロバイトのファイルのハッシュが一致します。
圧縮前のフォルダ全体のハッシュを取って添付するルールのところがありますが、これだけでは、旧型フォントが破損しているかどうかは判別不能です。だって、ゴミを捨てただけで壊してなんかないもんwって扱いになるからです。
ファイルサイズが0だったら本体を捨てられた可哀そうなフォントだと思えば大体合ってます。
まだ使えるようにしてあるmacにはちょっと感心します。売り物のフォントは高いもん。
/private/var/folders/なんか/なんか/以下に作られるIndesignのリカバリデータベースかなんかのファイルがアホみたいに溜まってました。
起動時に数ファイル作られ、正常終了すると全部消える仕様ですが、正常終了できないとそのまま残って次回起動時には別に新しく作られます。
OSを再起動しても勝手に消えるところではないので、これがたまり続けて幾星霜。30GBくらい溜まってました。
起動ディスクはSSDなので、そんなに容量がなく、こんだけ空くとでかいです。
