いろいろ検索してみると逆の事例のほうが多いようだ。

それぞれ似た機能だがいくつかの違いがある。

ハードリンク

Windows 3.1から使える。
1つのファイルに複数の名前(パス)を付けることが出来る。

ファイルの中身は共用して名前だけを増やすので、コピーした場合と比べて

• ディスク領域を節約できる。
• 片方の名前で開いたものを更新すると、ほかの名前で開いたものにも自動的に反映される。

等のメリットがある。

ジャンクション

Windows 2000から使える。
ハードリンクとの違いは

• ディレクトリにも張ることができる
• ドライブをまたいで張ることができる
• ハードリンクではすべての名前は対等なのですべての名前を削除するまでファイル本体が削除されることはないが、シンボリックリンクは別名に過ぎないので、本名を削除した時点で本体が削除されてしまい、別名で参照することもできなくなる。
• リネームして同名のファイルを作り直すと、ハードリンクはリネームされたファイルを指し、シンボリックリンクは同名で作り直されたほうのファイルを指すようになる(ハードリンクの仕様はアプリケーションのバックアップファイルの作成方法によっては不便かもしれない)。

Windows 2000/XPではファイルシステム(NTFS)にリパースポイントという機能が追加され、このリパースポイントを利用してジャンクションというシンボリックリンクに非常によく似た機能がサポートされている。

シンボリックリンク

Windows Vistaから使える。
強化版ジャンクションであり、UNIXのシンボリックリンクと同一の機能を持つ。ジャンクションがシンボリックリンクの下位互換版だとしたら、これは「本物のシンボリックリンク」。
ジャンクションには以下の弱点があった

• 標準ではファイルに張ることができない。
• ネットワークドライブやUNCパス上のファイルには張れない。
• 相対パスのリンクを作ることができない

が、シンボリックリンクではこれが解消されている。
Windows Vistaのシンボリックリンクもリパースポイントによって実装されているが、ジャンクションとはリパースタグ(リパースポイントの種類を識別する数値)が異なるため互換性がない。

なお、このツールでアクセスした場合、ネットワークドライブやUNCパス上のリンクをたどれないという制限があります。Windows Vistaのシンボリックリンクにネットワーク経由でアクセスするには、SMB 2.0を実装する必要があるようです。ただし、リンク先がネットワークドライブやUNCパスであるようなリンクでもリンク自体がローカルドライブにあればアクセスは可能です。

引用元/参考: リンク/ジャンクション作成ツール

Dropboxと組み合わせて使う

これらのファイルシステムの機能をファイル同期/共有/版管理ツールDropboxと一緒に使うと便利である。

が、残念な事にいくつかの制限がある。主に障害を起こす要因は、「Dropboxフォルダ内のファイルの実体は版別にApplication Dataフォルダにキャッシュされている物」というDropboxの仕様である。

例えば、何らかのファイルに対してハードリンクをDropbox外からDropbox内に張っても、一見うまくいったように見えて最初の1回以降は同期をしてくれない。

これは実際に外側にあるファイルのプロパティを見てみればわかるが(要Link Shell Extension)、ハードリンクで生まれた別名リンクの実体がDropboxフォルダではなくDropboxの版別キャッシュフォルダ(Application Data内)に配置されてしまっているからである。

僕が試した限り、逆向きにハードリンクを作っても同じだった。

片方がVista、片方がXPという環境なので(少なくとも純正のドライバでは)シンボリックリンクが使えず、ジャンクションはファイル単位で張れないという仕様が今回の用途では問題なので、ひとまずここで不完全燃焼のまま検証を終了した。

進展があればまたこのブログで報告したい。

追記:
シンボリックリンクを作った後にDropboxの再起動が必要だということがわかった。これで、USBメモリ上のファイルをDropboxでバージョン管理&バックアップするといった特殊な使い方も可能になる。
参考: 吾輩はブログである。名前は未だ無い: Dropbox を使う際の注意

perl -p -i -e s/APXS2=\$\(shell which apxs2\)/APXS2=\/usr\/sbin\/apxs/g Makefile

ではだめ。

perl -p -i -e ‘s/APXS2=\$\(shell which apxs2\)/APXS2=\/usr\/sbin\/apxs/g’ Makefile

こうすれば動く。
スペースが問題っぽい。

utterramblings(何て読むんだ)リポジトリを入れておけばCentOS標準リポジトリやRPMforgeにはないxcacheもyumで管理が出来るようになる。

これを入れておくとそれ以外にもphp5.2.6を入れることが出来たり様々なモジュールを5.2.6用に更新することが出来たりといろいろ役立つ。

追記:
おそらくyumの動作とはこういうものだと思う。後で詳しく調べる。

• リポジトリを追加してyumでupdateやinstallをかけるとバージョンが古い物が上書きされる。
• /etc/yum.repos.d/ディレクトリにあるリポジトリ別の設定ファイルでenabled=1を選択しない限り、追加リポジトリは毎日の自動yum updateの範疇には入らない。
• よって、毎日の自動yum updateでCentOS標準リポジトリのUpdateが既に追加リポジトリを使って更新/インストール済みのアプリケーションに適用されてしまいバージョンがダウングレードしてしまう等といった事にはならない。
• 複数のリポジトリをカンマ区切りで選択してyum install/updateを行った場合、アプリケーションは選択したリポジトリの中で一番新しいバージョンに更新される。
• 複数リポジトリの選択方法は具体的に言うと –enablerepo=utterramblings,rpmforge 等とする。CentOS標準リポジトリは無効化しない限り自動で範疇に含まれる。
• 追加リポジトリを扱う時はちゃんと範囲を絞らないと意図しないアプリケーションまでそのリポジトリの中での最新版に更新されてしまうので細心の注意を計る。(例 enablerepoされた状態でyum updateは絶対にせずyum update php のようにする等)

System Explorerでもいいけど。

とにかくAmazonの画像URLは大量に形式がある。
95年から営業してると過去のしがらみが多いということなのだろうか。
09年6月23日現在はこんな感じで好きな商品の好きなサイズの画像が手に入る。

http://ec2.images-amazon.com/images/I/(商品ページ画像URLに含まれる文字列)._SL(横幅のpx数)_.jpg

(商品ページ画像URLに含まれる文字列)の所をASINにするのが少し前までの習わしだったが、今はそれをやると横幅を指定した画像を取ることが出来ない。全く意味がわからない。現在のこの文字列の法則性は不明。

こういうエラーがcron経由で5分おきに送られてきているならmuninまわりのディレクトリ設定にミスがあるので、/etc/munin/munin.conf や /etc/httpd/conf.d/munin.conf などをいじってなんとかする。

具体的には以下など参照
CentOSにmuninをインストール – yukiwataの日記
CentOS に Munin をインストールする – Enjoi Blog
[munin] どうしてもApacheをインストールできない場合 – nullpopopo

とりあえず本家で修正されるまではその部分をDegCなりに変更してお茶を濁す。
参考 http://www.sandeinc.com/~eguchi/diary/20080731.html