Home

技術系のメモと日々の雑感

svn cleanup でも修正できないエラー

svn update を実行したら cleanup でも回避できないエラーが発生。

$ svn cleanup
svn: Can't open directory 'tmp/test1/.svn/tmp': No such file or directory

ディレクトリがないそうな。
それじゃ作るしかないね。
原因が分からないのが気がかりだけど、気を取り直して再度 svn update してみると

$ svn update
svn: 'svn+ssh://XXX.XXX.XXX.XXX/home/svn/repo_dev01/test1' is not the same repository as 'svn+ssh://hoge@example.com/home/svn/repo_dev01'

あれ?
何が起こってるんだろ。
svn status を叩いてみたら、メッセージが出ているディレクトリの内容が変更されているとのこと。
Subversion が面倒見きれないって言ってる以上(?)、残念ながらこの変更箇所は捨てるしかないね。
一旦トップディレクトリ(repo_dev01)からバッサリ削除して、svn checkout しなおしたらようやく復旧。
まぁ、例によって結果オーライということで・・・。

vim のヒストリ

vim では過去に実行したコマンドがヒストリに残っているので再利用することができるそうな。
実は、つい最近までヒストリを表示させる方法を知らなかったので、この機能はまったく使ってなかった。
というか、ヒストリを表示させるつもりがないときに出てくることがあって、ずっと疑問に感じてたんだけど。
この前、vim のオートインデントの情報を見付けたときに、偶然この操作も分かった。
「:」で一旦コマンドラインモードに移ってから Ctrl+F すればいいんだね。
スクロールしようと思って Ctrl+F を入力したつもりが、誤って先に「:」を入力してしまって混乱していたわけだ。
謎が解けた・・・。
vim とは結構長い付き合いだけど、まだ全体の1割の機能も使ってないような気がするなぁ。

Windows で smartctl

前回の「smartctl の出力についてまとめてみた」に引き続き、今回は Windows で smartctl を使ってみた。
Windows 用の smartmontools は Cygwin 上でしか使えないだろうという先入観があったけど、調べてみるとネイティブ版もあった。
http://sourceforge.net/project/showfiles.php?group_id=64297
ダウンロードしたセットアップファイルを実行するとインストーラが走る。
smartctl.exe を使うだけなら「Installation Options」の画面で「Extract files only」を選んで展開するだけでよかった。
BIOS で SMART が有効になっていても機能が無効になっていることがあって、デバイス情報のセクションに

SMART Disabled. Use option -s with argument 'on' to enable it.

と表示されたときは、親切なメッセージに従って

smartctl -s on /dev/hd?

で有効にすれば大丈夫だった。
HDD の指定が Linux と同じ /dev/hd? なのが面白い。
出力される情報は全体的に Linux のときと似たようなものだけど、よく見るとデバイス情報のセクションに

SMART support is: Available - device has SMART capability.
                  Enabled status cached by OS, trying SMART RETURN STATUS cmd.

という表示が。
OS がステータスをキャッシュする機能を有効にしたので SMART RETURN STATUS コマンドを試せ?
・・・。
まぁ、気にしなくても問題なさそうだな。
ちなみに、今回 smartctl を試したマシンの HDD はエラーが出まくっていたのでちょっと焦ってしまった。
イベントログにはそれらしき出力はまったくなかったのに。
あ〜、早くバックアップを取らないとマズいなぁ。

grub.conf と menu.lst (続き)

前に CentOS の GRUB は grub.conf を参照しているというエントリを書いたけど、先日 Vine 4.2 を使ったときに CentOS とまったく逆の設定になっていることに気付いた。
つまり、menu.lst がファイルとして存在していて、それに対するシンボリックリンクが grub.conf になっていた。
これって一体?
念のために GRUB がどっちを参照しているのか確かめてみると、grub.conf(シンボリックリンク)を削除して menu.lst だけにしてみたときは問題はなくて、grub.conf だけにしてみたら起動しなくなった。
予想はしてたけど動作も CentOS とまったく逆だ。
ディストリビューションのポリシーの違いといったらそれまでだけど、ここまで真逆にする理由って何なんだろう。
謎は深まるばかり。