コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2010年4月10日 >>> 2010年3月28日
link もっと後

2010年4月10日

使いづらいエクスプローラ

週末を利用して旧マシンを葬って、新マシンを立ち上げました。

Windows 7は悪くないと思うのですが、エクスプローラが最悪です。エクスプローラを捨てて別のファイラーにすべきなのか悩みましたが、エクスプローラで無理矢理頑張ることにしました。

無駄な努力かもしれないけれど

エクスプローラのフォルダツリーにおいて邪魔くさい輩は下記のとおり。

お気に入り
一番上に鎮座しているため、最強に邪魔くさい。真っ先に消えていただきたい。
ライブラリ
各フォルダへのシンボリックリンクを張る機能ですが、フォルダツリーに固定表示されるのはいただけない。要らない子。
ホームグループ
一人で使ってるネットワークだし、仮に複数人で使うとしてもこの機能は使わない。つまり要らない子。
ユーザのドキュメント
(XP時代からあったけど)ここに保存するとOSのドライブに保存されてしまいアクセスが遅いので嫌い。実体のフォルダがやたら深いところに置かれるのも嫌い。よって要らない子。

いずれも便利ですよ、MS的にはオススメしたいんです!という気持ちは伝わるんですけど、強制ONのままOFFにできないのはいただけないです。私は要らないのです。

以下、削除方法です。
参考: Windows 7 Notes, Registry, Hacks, Tips

お気に入り
HKEY_CLASSES_ROOT\CLSID\{323CA680-C24D-4099-B94D-446DD2D7249E}\ShellFolderのアクセス許可変更後(※)下記の値を
Attributes=dword:a9400100
PinToNameSpaceTree=""
に変更する。
ライブラリ
お気に入りと同じ方式(アクセス許可変更必要)か、あるいはHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace\{031E4825-7B94-4dc3-B131-E946B44C8DD5}を適当に(先頭に1文字足すなど)リネーム。
キーの(規定)アイテムに「UsersLibraries」の値が入っているキーです。
ホームグループ
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace\{B4FB3F98-C1EA-428d-A78A-D1F5659CBA93}を適当に(先頭に1文字足すなど)リネーム。
キーの(規定)アイテムに「Other Users」の値が入っているキーです。
ユーザのドキュメント
わからん…。また後で調べて更新します。

上記操作によりお使いのWindows 7がおかしくなっても知りません。自己責任でお願いします。

(※)レジストリエディタにてアクセス許可を変更したいキーを右クリック [アクセス許可(P)] - [詳細設定(V)] - [所有者タブ] - [現在の所有者を変更] にて自分が所属するグループ(例: Administrators)に変更 - [OK] で閉じます。
その後 [Administratorsを選択] - [Administratorsのアクセス許可(P) リスト] - [フル コントロールにチェック] - [OK] で閉じればOKです。
変更後は元に戻すのをお忘れなく!

編集者:すずき(2010/04/28 23:38)

コメント一覧

  • hdkさん(2010/04/12 10:15)
    ユーザのドキュメントは普通に場所を別のドライブとかに変更すればいいんじゃない? あるいは NTFS の、ディレクトリにマウントという技を活用する手もあり。
  • すずきさん(2010/04/15 22:31)
    >hdkさん
    リンク先を変えるのか、なるほどやってみます。
    ちょうど消し方がわからなくて困っていたところでした…w
open/close この記事にコメントする



2010年4月6日

うるさいファン

以前から調子の悪かったチップセットファンですが、最近になっていよいよ壊れたらしく、PCが電源ONの間ずっと「ウィウィウィー!ガガガガー!」という爆音を発しています。

軸が曲がったのかなあと思って、ファンの真ん中をグリグリ押したり引っ張ったりしていたら、ファンのブレード&モータが台からもげました。しかも台側の回路と思しき部分が剥がれてしまいました。

ブレードを台に無理矢理戻したら動くかな?という考えがよぎりましたが、極細の銅線がぶっちぎれているを見つけたのでやめました。下手にショートさせてマザーボード壊すのも馬鹿らしいですから。

これを機に旧マシンは引退させて新マシンに移れということですね。

ネック

ニューマシンはWindows 7 64bit版なのがネックといえばネックです。それもこれも今までWindows XP 32bit版で粘ってたツケに過ぎないのですが…。

Windows 7で同じ環境が作れるか?というチェックがかなり面倒くさいけども、いい加減に旧世代の遺物は卒業して、時代に追いつくように頑張らんとね…。

編集者:すずき(2010/04/07 02:14)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2010年3月31日

ウイルスチェック高速化(予想)

先日(2010年3月30日の日記参照)の続き。

ファイルに対してできるアクセスは、読み(実行は読み込みを伴うので読み込みの一種)、書き(削除は書き込みの一種)のどちらかです。ウイルスが悪さするアクセスパターンは下記の通りです。

既存読み書きチェック必要性起きうる悪意
× 既存ファイルからウイルスを読み出す
× 既存ファイルを消す、ウイルスを書き込む
× × × なし(誰も触らないファイル)
× × × なし(存在しないファイル、つまり読めない)
× × 新規ファイルにウイルスを書き込む
× × × × なし(存在しないファイル)

既存ファイルの読み出し、既存ファイルへの上書きは即時にチェック(チェックの必要性が ○)しますが、新規ファイルへの書き込みはスキップ(チェックの必要性が △)できます。

理由は全読み込みアクセスをチェックできれば、後の読み込み時のチェックで「十分」であるため、ですが…説明になっていないので、ウイルスを新規作成したときの動作で考えてみましょう。

ウイルスファイルが新規作成されても、それだけで悪さはできません。悪さをするには、ウイルスファイルを実行するか、既存ファイルにウイルスデータを混ぜて良いファイルのふりをして実行する必要があります。

実行にせよ書き込みにせよ、一度は新規作成したウイルスファイルの読み込みを経なければなりません。つまり新規作成されたウイルスファイルが悪さをするには、新規作成されたウイルスファイルの読み込みが必要です。

新規作成されたウイルスが読み込まれる時にチェックできれば、新規作成されたウイルスが悪さするのを十分阻止できる、といえます。

ローカルドライブへのコピーが速いわけ(予想)

先の結論をまとめると、

  1. ウイルスが新規作成されただけならば、ウイルスは悪さできない
  2. 新規作成されたウイルスが悪さするには、読み込みが必要
  3. 全読み込みをチェックできれば、悪さできない

要は全読み込みをチェックできるなら、新規作成時のウイルスチェックは不要であり、「新規作成時にウイルスチェック」をサボって「後に読み込む時にウイルスチェック」(これこそ遅延評価ですね!)をすると速くなることが予想されます。

さて懸案のローカルドライブへのファイルコピーを先ほどの表に当てはめてみると、下記のようになります。

既存読み書きチェック必要?起きうる悪意コピー動作に当てはめると
× 既存ファイルからウイルスを読み出す(発生しない)
× 既存ファイルを消す、ウイルスを書き込む上書きコピー
× × × なし(誰も触らないファイル)(発生しない)
× × × なし(存在しないファイル、つまり読めない)(発生しない)
× × 新規ファイルにウイルスを書き込む新規コピー
× × × × なし(存在しないファイル)(発生しない)

確認すると、私が実行するコピー作業の9割以上が新規コピーで、上書きコピーはほとんどありませんでした。新規コピーファイルのチェック遅延が効果的に効くため、ローカルドライブへのコピー作業は非常に速いのだと思われます。

ネットワークドライブへのコピーが遅いわけ(予想)

ローカルドライブでは遅延評価により高速化が望めましたが、ネットワークドライブに関しては「3. 全読み込みをチェックできれば、ウイルスは悪さできない」が成立しないため、遅延評価ができません。下記にローカルドライブとの違いを挙げます。

ローカルドライブ
自身しかアクセスする可能性がないため、全読み出しをチェック可能。
ネットワークドライブ
他者からアクセスされる可能性があるため、全読み出しをチェック不可能。

このため新規作成のファイルも全てチェックする必要があります。だからネットワークドライブへのコピーは非常に遅いのです。

編集者:すずき(2010/03/31 00:12)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2010年3月30日

遅延評価

先日(2010年3月28日の日記参照)の続き。

さてKaspersky先生、なぜにネットワークドライブへのコピーだとウイルスチェックがこんな重いのでしょう?

予想するにローカルドライブ間のコピーは遅延評価しているので高速ですが、ネットワークドライブへのコピーでは全数チェックするので、遅いのでしょう。

とりあえず日本語で話せよ?な?って人は、以降を読むとわかったような気になれるかもしれません。興味ない?あ、そう…。

遅延評価とは何か

ざっくり言えば「やれと言われた時にやらず、後で必要になったときにやる」という手法です。この手法は、

  1. 作業に時間がかかる
  2. 作業の結果が後々無駄になる可能性が高い

という時に非常に有効な作戦です。

ウイルスワクチンソフトも同様の作戦が使えます。PCが遅い!とお嘆きのユーザのため、サボれるチェックをとことんサボって高速化させているものと予想されます。

ただし遅延評価で気をつけたいのは2. の判定が難しく、見誤ると逆に効率が悪くなることです(1. は実際やって時間でも計れば自明です)。

見誤った例としては、「勉強はテスト前に〜」「ダイエットは明日から〜」が良い例でしょうか。勉強やダイエットは、作業に時間がかかります(1. は成立)が、後々無駄になることは少ない(2. は不成立)です。

続きはWeb…じゃなくて、明日にでも…。

編集者:すずき(2010/03/30 23:57)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2010年3月29日

FTOとお別れ

目次:

三菱のディーラーにてFTOを手放す手続きをしてきました。その後は廃車になると思っていたのですが、聞いてみると中古車オークションに流すのだそうです。

私のFTOがマイナーチェンジ前の最上位グレードGPXだったため、ディーラーにて中古車として売れる可能性ありと判断していただいたようです。おかげで少しだけお金が返ってきました。

さよならFTO

最近はあまり乗る機会もなく、ホコリ被り気味のFTOでしたが、いざ手放すとなると寂しいものです。

FTOは大学2年で買ってもらったので2002年〜2010年の8年間に渡り頑張ってくれました。実に人生の1/3を共に過ごした車なのです。

思い起こせば、大学時代には普段乗りも遠出も色んな所行ったなあ。富士山登ったりもしたなあ。社会人時代だとつくば〜大阪往復が一番ロングドライブかな?あれはもうやりたくないんだぜ…。

ちゃっかりリコール対象車だったり、エンジンがトラブってバイト代が飛んだりもしたっけ。それもまた良い思い出。

次のオーナーが見つかるか、はたまた廃車かはわかりませんが…。FTOお疲れ様、さようなら

楽しい車を作ってくれた三菱の人々に感謝です。次(いつになるやらわからないけど)の車も大切に乗りたいと思います。

代休

3日分あった代休ですが、今日で最後です。

編集者:すずき(2023/09/30 15:24)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2010年3月28日

Sambaサーバへのコピーが異常に遅い

家のファイルサーバにファイルをコピーする際、異常に遅くてイライラします。

小さなファイルの転送が遅すぎます。1秒に数ファイルも送れません。転送しているファイルのサイズはどれもたかだか数KBで、転送元のWindowsマシンとファイルサーバとは、ギガビットイーサネットで接続しているにも関わらずです。

ネットワークの使用率を見ても、1MB/sも出ているかどうか怪しい状態です。

サーバ側はどうか

前のサーバでは起こっていなかったので、サーバの設定が怪しいのでしょうか?

真っ先に浮かぶのはSambaの設定ですが、以前から変えていません。

他に思い当たる節は、ファイルシステムをReiserFSからXFSにした(※)くらいですが、そんなことが影響するとは思えません。だってtarballの展開とか、rsyncとか、cp -rは速いんですよ。

(※)ReiserFSはマウント時のfsckが他のジャーナリングファイルシステムに比べてかなり遅いのと、マウント時の変な音が嫌なのです。
変な音って何と言われてもうまく伝えられないのですが、マウント開始から数秒間はカカカカ…、その後はガガッガガガッ…という音が続きます。やたらとディスクに負荷かかってそうな音です。

クライアント側はどうか

ファイルコピー中にWindows側をよく見ると、Kaspersky先生が元気に動いていることに気づきました。

ローカルドライブへのコピーだとこんなこと起きないので、いやーまさかと思って Kasperskyを止めてからファイルコピーしたところ、超速い。体感速度10倍以上です。

クライアント側がおかしかったのに、サーバに原因がありそうなんて疑ってかかったものだから、余計な時間を食いました。変な経験則から偏った見方をすると、人間、目が曇りますね。

編集者:すずき(2010/03/30 02:44)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2010年4月10日 >>> 2010年3月28日
link もっと後

管理用メニュー

link 記事を新規作成

<2010>
<<<04>>>
----123
45678910
11121314151617
18192021222324
252627282930-

最近のコメント5件

  • link 21年9月20日
    すずきさん (11/19 01:04)
    「It was my pleasure.」
  • link 21年9月20日
    whtさん (11/17 23:41)
    「This blog solves my ...」
  • link 24年10月1日
    すずきさん (10/06 03:41)
    「xrdpで十分動作しているので、Wayl...」
  • link 24年10月1日
    hdkさん (10/03 19:05)
    「GNOMEをお使いでしたら今はWayla...」
  • link 24年10月1日
    すずきさん (10/03 10:12)
    「私は逆にVNCサーバーに繋ぐ使い方をした...」

最近の記事3件

  • link 23年4月10日
    すずき (11/15 23:48)
    「[Linux - まとめリンク] 目次: Linux関係の深いまとめリンク。目次: RISC-V目次: ROCK64/ROCK...」
  • link 24年11月6日
    すずき (11/15 23:47)
    「[Ubuntu 24.04 LTS on ThinkPad X1 Carbon Gen 12] 目次: Linux会社ではTh...」
  • link 24年11月11日
    すずき (11/15 23:26)
    「[Pythonのテストフレームワーク] 目次: Python最近Pythonを触ることが増えたのでテストについて調べようと思い...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 11/19 01:04