<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title><![CDATA[PCと解 掲示板 - chkdsk /r を実行するリスク]]></title>
		<link>https://pctrouble.net/bbs/topic/327/</link>
		<atom:link href="https://pctrouble.net/bbs/feed/rss/topic/327/" rel="self" type="application/rss+xml" />
		<description><![CDATA[chkdsk /r を実行するリスク の中の最新の投稿]]></description>
		<lastBuildDate>Wed, 19 Feb 2020 16:47:24 +0000</lastBuildDate>
		<generator>PunBB</generator>
		<item>
			<title><![CDATA[Re: chkdsk /r を実行するリスク]]></title>
			<link>https://pctrouble.net/bbs/post/1052/#p1052</link>
			<description><![CDATA[<p>そう、そういう本ってないんですよね。<br />あっても、内容が浅かったり、方向性が違ったり。</p><p>結論から言うと、ないと思います。<br />そんな本が世に出ないのも、なんとなく理解できます。<br />そういったノウハウは、パソコンの修理サポート業者にとって生命線だからです。</p><p>現場は応用問題なので、基礎から体系化されていないというのもあります。<br />私の当時の職場にも、マニュアルのようなものはなく、<br />「見て、やって覚えろ」みたいな感じでした。<br />お客さんが100人いれば、100通りの問題があったりするので。</p><p>私がパソコンの修理サポートを主にやっていた時、<br />パソコントラブルについてWebで検索すると、Yahoo!知恵袋ばかり表示され、<br />しかも未解決のまま、というのがほとんどでした。<br />でも、私は目の前にお客さんがいるので、どうにかしなければなりません。<br />で、どうしたかというと、ジャンク品を使っていろいろ実験したのです。<br />お客さんのパソコンで、いきなり実行するわけにはいきませんでしたから。</p><p>私の立場的にジャンク品が集まりやすく、しかもジャンク品になった経緯も知っているので、<br />不具合の再現実験をするには恵まれた環境だったと言えるかもしれません。<br />私の力不足で対応できなければ、<br />先輩や、メーカーに修理を依頼し、その結果から知識を得ることもありました。<br />要は、日々の業務で積み上げていくしかなんじゃないかと。</p><p>本当にお客さんって、「そんなことする？」っていう人いますからね。<br />そのおかげで発見できることもあるので、いいのか悪いのかわかりませんが。</p>]]></description>
			<author><![CDATA[null@example.com (web404)]]></author>
			<pubDate>Wed, 19 Feb 2020 16:47:24 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1052/#p1052</guid>
		</item>
		<item>
			<title><![CDATA[Re: chkdsk /r を実行するリスク]]></title>
			<link>https://pctrouble.net/bbs/post/1050/#p1050</link>
			<description><![CDATA[<p>ruurooさん、いつも丁寧にお返事頂きありがとうございます。<br />実は当方、ソフト屋の端くれで、PC込みで納品することが多いのですが、PCやWindowsには疎いのです。<br />ユーザーさんの多くはもっと疎くて、「普通の使い方」をしてくれません。PCが起動中でもお構いなしに電源ケーブルを抜きます。</p><p>そんなわけで、ファイルが壊れ（正確にはファイルシステムのテーブルにはエントリーがあるのにデータ本体は完全に書き込まれてなかった状態、でしょうか。）ソフトがそのファイルを開きに行く時にソフトがエラーを吐く、という場面にたまに出くわすのです。<br />以前、そういう現場の対応に行って、データをバックアップしている最中に壊れたファイルが見つかり、その後、「chkdskは壊れたファイルを直してくれる神ツール」という誤解のもと、chkdsk /rを実行したことがあります。その時chkdskの結果に当該ファイル名とともに初めて、「不良クラスター」という表示を目にしたのを憶えています。</p><p>先のruuroさんの返信の内容を踏まえると、こういう風に問題箇所が特定できている場合は、chkdsk /f は確かに安心して使えそうです。</p><p>私はこのサイトに出会うまで、先輩に教えられたとおり、定期点検と称してバックアップも取らずにユーザーのPCに修復オプションつきの「チェックディスク」をかけ、不良セクターが見つかると即ハードディスクの交換を勧めていました。無知とは本当に恐ろしいものです。</p><p>今、勉強のためにハードディスクの仕組みに関するちゃんとしたソースを探しています。問題があった時の対処法とそれを裏付ける基礎知識が網羅されたようなものがあるといいのですが、洋書でもなかなか良いものが見つかりません。お勧めがあれば教えてください。あつかましくてすみません。</p>]]></description>
			<author><![CDATA[null@example.com (esk2)]]></author>
			<pubDate>Tue, 18 Feb 2020 05:37:14 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1050/#p1050</guid>
		</item>
		<item>
			<title><![CDATA[Re: chkdsk /r を実行するリスク]]></title>
			<link>https://pctrouble.net/bbs/post/1048/#p1048</link>
			<description><![CDATA[<p>そもそも、普通に機器を使っている限りは、ファイルシステムが壊れるようなことはめったに起きないので、<br />そこまで心配する必要はないと思います。</p>]]></description>
			<author><![CDATA[null@example.com (web404)]]></author>
			<pubDate>Fri, 14 Feb 2020 14:28:07 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1048/#p1048</guid>
		</item>
		<item>
			<title><![CDATA[Re: chkdsk /r を実行するリスク]]></title>
			<link>https://pctrouble.net/bbs/post/1047/#p1047</link>
			<description><![CDATA[<p>esk2さんはちょっと神経質に考えすぎかもしれませんが、心配される気持ちはよくわかります。<br />書かれた内容は、的を射ています。</p><br /><p>「chkdsk」は、有用です。<br />当サイトの<a href="https://pctrouble.net/running/chkdsk.html" target="_blank" rel="ugc noopener">「chkdsk」解説ページ</a>も、当サイト立ち上げ初期（10年以上前）に書いたものを元に修正を繰り返したものなので、<br />今回の一連のご質問を受けて、改めて書き直そうと思います。</p><p>私がこの記事で言いたかったことは、<br /></p><ul><li><p>「chkdsk」による修復にはリスクがある</p></li><li><p>「chkdsk /r」はハードディスクに対する負荷が高い</p></li><li><p>「chkdsk /f」でことたりる場合がほとんど</p></li></ul><p>というのが大部分です。<br />当時、「とりあえず「chkdsk /r」を実行しとけ」みたいな風潮があり、<br />「それはやめたほうがいい」というアンチテーゼのつもりでした。<br />お客さんのパソコンにいきなり「chkdsk /r」を実行して、<br />その後ハードディスクが読めなくなった現場を見ていますので。</p><br /><p>「chkdsk」のリスクは、大きく2つに分けられます。<br /></p><ul><li><p>ハードディスクの損傷が進む</p></li><li><p>ファイルが消失することがある</p></li></ul><p>つまり、物理的か論理的かの違いです。<br />前者はハードディスクの状態が末期的な場合で、イメージしやすいと思います。<br />多分、気になっているのは後者だと思いますが、<br />「chkdsk」で消失するファイルには、ある程度の傾向があります。</p><p>「chkdsk」も、積極的にデータを消すわけではありません。<br />できるだけ安全に動作しようとします。<br />「chkdsk」で修復を試みるということは、現状のファイルシステムに問題があるはずです。<br />この、<strong>ファイルシステムに問題が発生した、直前のファイル操作に関するファイルが影響を受ける可能性が極めて高い</strong>です。<br />従って、使う頻度が低いファイルは、壊れたり失われたりするリスクは低いです。</p><p>「chkdsk」によってファイルが削除されたとしても、ファイル復元ソフトを使ってファイルを復元すればよさそうですが、<br />ファイルが見つからなかったり、サイズが0バイトになっていて、データが失われていることがあります。<br />このため、ファイルを復元するならそっちが先で、「chkdsk」は後回しにすべきなのです。</p><p>それでも「chkdsk」が有用なのは、<strong>「chkdsk」で修復しなければ、ファイル操作ができない</strong>からです。<br />ファイルシステムに異常がある状態では、ファイルの保存、削除、編集ができないことがあります。<br />できるだけ現状を維持したまま、異常が発生したドライブを使い続けるためには、<br />「chkdsk」で修復するしかありません。</p><br /><p>本当は、こういうのは百聞は一見にしかずで、私が何を書くよりも、<br />起動時に「chkdsk」が走って起動できないパソコンとか、<br />「chkdsk」を実行してファイルが消えた現場を目にするのが、一番わかりやすいんですけどね。</p><p>ソフトウェアは、データを失うことがないよう動作を試みますが、<br />ハードウェアは、いつどこでどのような不具合を起こすのか予測不能なので、<br />今ある状態でより良い選択をするしかありません。<br />本当に重要なデータが存在するなら、ミラーリングと定期バックアップを組み合わせるしかないと思います。<br />店のシステムがそうだったように。</p><p>私は極論、システムは動いてさえいればいいぐらいの気持ちで割り切っています。<br />たとえ欠損のないデータであったとしても、ソフトウェアにバグや欠陥はつきものなので。<br />世の中に完璧なものはありませんからね。</p>]]></description>
			<author><![CDATA[null@example.com (web404)]]></author>
			<pubDate>Fri, 14 Feb 2020 13:47:25 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1047/#p1047</guid>
		</item>
		<item>
			<title><![CDATA[Re: chkdsk /r を実行するリスク]]></title>
			<link>https://pctrouble.net/bbs/post/1045/#p1045</link>
			<description><![CDATA[<p>ruuroo さんお返事ありがとうございます。</p><p>chkdsk /f ですら安心して使えないとなると、ますますchkdskの使いどころが分からなくなりました。</p><p>私は、ディスクの問題を解決するなんらかの試みをする前には、このサイトや他の著作を参考にして、失っては困るデータを必ずバックアップを取っています。<br />とは言え、「大事なデータ」のうち特に頻繁に使うデータは、不具合があれば比較的早く気がついて、バックアップから復元する事ができますが、重要でも使う頻度が低いものは不具合があっても気が付きにくいし、そもそもバックアップの対象になりにくいと思われます。<br />つまり何が言いたいかと言うと、データを失う危険があるという前提がある以上、chkdskを実行することは、ディスク上のシステムやアプリケーションを含むあらゆるデータの信頼性を損ねるもので、有体に言えば、いつ爆発するか分からない地雷を、自ら眼を瞑ってばら撒いているかのようです。大袈裟かもしれませんが。<br />もしディスク上のデータの信頼性を維持したいのであれば、ファイルシステムの管理情報が壊れた、とか、不良セクターが見つかった等の問題が生じた場合には、大事なデータのバックアップを取った後は下手なことをせず、新品のハードディスクにシステムやアプリケーションをリストアすることではないかと言う気がします。立派な会社のデータセンターでもあるまいし、何もそこまで考えずとも、とも思いますが。<br />結局のところ、chkdskに限らず、調子の悪いディスクに何かを試みる場合は、本当に大事なデータとその他代替が効くデータを切り分け、前者を守るために後者が犠牲になるかもしれないという覚悟の上で行うべし、という事のような気がします。<br />何か思い違いをしていたら指摘してください。</p>]]></description>
			<author><![CDATA[null@example.com (esk2)]]></author>
			<pubDate>Thu, 13 Feb 2020 11:26:05 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1045/#p1045</guid>
		</item>
		<item>
			<title><![CDATA[Re: chkdsk /r を実行するリスク]]></title>
			<link>https://pctrouble.net/bbs/post/1043/#p1043</link>
			<description><![CDATA[<p>修復オプションを指定した「chkdsk」は、無害ではありません。<br /><strong>必ず、現在のファイルシステムの管理情報を上書きする</strong>からです。<br />不良セクタが存在しなくても、「chkdsk /f」でも、<br />今までアクセスできたファイルにアクセスできなくなる可能性はあります。</p><p><strong>不良セクタの有無と、ファイルシステムの完全性は別の話</strong>です。<br />不良セクタがなくても、ファイルシステムに問題が発生することはあります。</p><br /><div class="quotebox"><cite>esk2 さんのコメント:</cite><blockquote><p>私の理解では、ディスクのファームウェアは、あるセクターが一度で読み取れなかった場合は、ヘッドの磁力やタイミングを変えて何度か読み取りを再試行したり、その結果読み取りに成功しても一旦ペンディングにして次回のアクセスでミラーと照合したりと、データを保護する観点からは大変親切な設計です。chkdsk /r がディスクの全セクタをスキャンする際はこれとは異なる仕組みなのでしょうか。</p></blockquote></div><p>異なるわけではありません。<br />ハードディスクのその仕組みも、常に狙ったとおりに機能するものではありません。<br />ハードディスクの信頼性は、そこまで高くないです。<br />大体、問題があるのはセクタではなく、ヘッドのほうなので。</p><p>たとえば、非常に状態の悪いハードディスクに対して「chkdsk」を実行すると、<br />ハードディスクの不良セクタを回避する仕組みがうまく機能せず、<br />しかし「chkdsk」は実行し続け、<br />ハードディスクのアクセスランプがついたままフリーズしたようになります。<br />強制終了するしかないのですが、当然ながら状況はさらに悪化します。</p><p>これは極端な例ですが、いずれにしても「chkdsk」による操作は元に戻せないので、<br />重要なデータがあるようなら、バックアップを最優先してください、ということです。<br />「chkdsk」を実行してどうにもならなくなったと持ってこられたパソコンは、<br />大概、もうどうにもなりません。</p><p>たとえば、当サイトで過去にあった問い合わせに、<br />「TestDisk」と「chkdsk」を併用して、しかも操作を間違えたという話がありましたが、<br />リカバリするしかなく、そうされたと記憶しています。</p>]]></description>
			<author><![CDATA[null@example.com (web404)]]></author>
			<pubDate>Wed, 12 Feb 2020 14:17:20 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1043/#p1043</guid>
		</item>
		<item>
			<title><![CDATA[chkdsk /r を実行するリスク]]></title>
			<link>https://pctrouble.net/bbs/post/1040/#p1040</link>
			<description><![CDATA[<p>引用箇所:&nbsp; &nbsp; <a href="https://pctrouble.net/running/chkdsk.html" target="_blank" rel="ugc noopener">https://pctrouble.net/running/chkdsk.html</a><br />＜引用文はじめ＞<br />「chkdsk」による修復の目的は、Windowsにとって正しいファイルシステムにすることです。<br />ユーザーにとって必要なファイルを修復することではありません。<br />従って、その過程でユーザーにとって必要なデータが上書きされることがあります。<br />＜引用文終わり＞</p><p>＜質問＞<br />chkdsk /rについて、別の箇所で「不良セクタを検出し、不良クラスタから読み出し可能なデータは回収する」<br />「不良セクタを含んだクラスタは不良クラスタとして、ファイルシステム上使わないようにするだけ」と書いていらっしゃいます。<br />他方、chkdsk /r を実行するリスクとして、「ユーザーにとって必要なデータが上書きされる」ともおっしゃっています。</p><p>前者2つの記述だけを読むと、chkdsk /r は無害であって、後者のようなリスクが生じる危ない仕組みのように思えません。<br />「ユーザーにとって必要なデータが上書きされる」シナリオは何故、そして、具体的にどのように起こるのでしょうか。</p><p>私の理解では、ディスクのファームウェアは、あるセクターが一度で読み取れなかった場合は、ヘッドの磁力やタイミングを変えて何度か読み取りを再試行したり、その結果読み取りに成功しても一旦ペンディングにして次回のアクセスでミラーと照合したりと、データを保護する観点からは大変親切な設計です。chkdsk /r がディスクの全セクタをスキャンする際はこれとは異なる仕組みなのでしょうか。</p><p>例えば、もし、chkdsk /r が一回のトライで読み取れなかったセクタは全て不良セクタと判定するような不親切な仕組みだとしたら、データが失われる確率が高くなるので、実行前に現存するデータを必ずバックアップしておくべきという考えは理解できます。</p><p>この数日、この疑問に悩まされています。英語のソースを含め、疑問を解決する情報が見当たらず行き詰っています。</p>]]></description>
			<author><![CDATA[null@example.com (esk2)]]></author>
			<pubDate>Tue, 11 Feb 2020 11:55:51 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1040/#p1040</guid>
		</item>
	</channel>
</rss>
