毎日モザイク

AFP Lionで既報のとおりだったのに、すっかり忘れててちょっとハマったw

Lion以降のAFPはデフォルトで、あんまり安全ではない接続を禁止しているので、設定を変更しないと古いAFPサービスには接続できません。

これに引っかかって、IO DATAのLAN DISK HDL-GTに接続できなくなりましたw

ググって見ると、一部では諦めてsmbやftpで接続したり、OSをLion以前に戻したりしているようですが、繋がらない原因は繋がらないダイアログに出ている通りなのでこちらの記事の方法で繋がります。

OSXのtexteditで作られたrtfファイルが来ることがあります。

その都度、texteditかJeditで開いてtxtに変換して使ってました。

知りませんでした。

標準のコマンドにtextutilなどという便利なものがあることを。

これさえあれば、

textutil -convert txt [対象ファイル]

で、何もせずにtxtに変換されるんですね。

これをbashに組んで、なんでもドロップレットにできるPlatypusでドロップレットにして、フォルダをドロップすれば一括で変換できるようにしました。

今までの手間は何だったのか？　レベルの楽さ。

bashは自分で使うモノしか書けないレベルで、例外処理は一切ありません。

#!/bin/bash

#ディレクトリが指定されてなかったら終了
if [ ! -d “$1” ]; then
echo “フォルダ専用”
exit 0
fi

(
#スペース対策
IFS=$’\n’;

#ファイル一覧を取得
_FILES=`ls $1 | grep ‘.*\.rtf$’`

#rtfをtxtに
for _FILE in ${_FILES}
do
textutil -convert txt ${1}/${_FILE}
done
)

これをPlatypusに食わせて、フォルダ対象のドロップレットにすればフォルダ内（再帰はしない）のrtfファイルが全部txtに

10.6から変わったこと。

マルチモニタの場合、アプリケーションスイッチャーはdockがある画面についていく。

netatalkにmacからファイルをコピーすると、リソースフォーク部分を管理する.Appledoubleという不可視フォルダができます。

これらの不可視ファイル／フォルダ群は邪悪な存在で、有名どころでは.DS_Storeが悪さをしますが、.Appledoubleもなかなか凶悪。

Appleshareのみの環境なら問題は出ませんが、同じディレクトリをFTPなどでも共有していると面倒なことに……。

Mac→netatalk

hage

これをls -laすると

hage .DS_Store .Appledouble

になっていて、これをFTPでgetすると、netatalkを経由しないので邪悪なフォルダ群がそのままコピーされます。

ここまでは何の問題も出ません。余分なクソフォルダがあるだけです。

これを、再度netatalkサーバにコピーしようとするとエラーが出てコピーできません。

afpdのログを見ると

check_name: illegal name: '.AppleDouble'

とあり、不正なフォルダ名なのでダメです。ということのようです。

ということで、netatalkの共有ボリュームから他の方法で落としたフォルダは、別のフォルダに移してからコピーするしかないようです。

OSXServerは仕組みが違うので平気でコピーできます。

OSXServerはファイル名にも寛容なので、Win/Mac他が混在する環境でのファイル共有は、OSXServerが一番簡単なのではないかと。

3.xでは、別の方法で管理するようですが、2.xのNASも多いので、NASで同じ現象が起こったら同じ原因でしょう。

ついでに。

netatalkほかで共有しあっているディレクトリを使うときは、マジでリソースフォークを使っている形式のファイルは止めた方がいいっていうか止めないと面倒です。

epsのpictプレビュー形式が典型的で、プレビュー部分が.AppleDoubleに入ってしまっていて、見えているファイルはプレビューなしになります

現行のwordpressは、標準でマルチサイト対応になっていて、そのバージョン以降はwwwつきURLにも対応しています。http://example.com/以下でなくても、http://example.com/hage/なんかにも設置できます。

それ以前は、www非推奨どころか非対応で、.htaccessでwwwなしのurlにリダイレクトして、apacheがwwwつきにリダイレクトして、.htaccessがwwwなしにリダイレクトして〜が、リダイレクト制限に達したところでアクセス不能になるという動作でした。

しかし、現行のバージョン（3.6）でも、一部のプラグインはその頃の仕様に合わせてあったり、http://expample.com/以下に設置する前提で決め打ちしてあるものもあって、動作確認が必要です。

wp-click-trackは、www非対応時代の仕様に引っかかっていて、カレンダー部分が表示されません。

wp-click-trackは非常に便利なのですが、決め打ち部分が割と多く、非標準の設置方法にすると何かと引っかかります。

それと、マルチサイト無効のものは問題ないのですが、マルチサイトを有効にしたものは管理画面が異様に遅いというおなじみの現象に見舞われます。

マルチサイト有効／無効での大きな違いは、.htaccessでmod_rewriteを使っているところで、コードをよく見ていないのでなんとなくですが、www非対応時代の名残があるのかも。

とりあえずの回避策は、使っているテーマのfunctions.phpに

<?php
add_filter( 'do_mu_upgrade','__return_false');
?>

を入れて、自動確認を無効にすれば爆速に戻ります。

これは、管理ページをリロードするたびに呼ばれ、そのつど更新確認をしに行くので、tail -f access.log を見ながら動かすだけで、明らかにそこで引っかかっているのがわかるほど時間がかかっています。

ここを無効にしても、ネットワーク管理者のダッシュボードで手動で確認できるので、特に問題ありません。