（もともと「Yahoo!知恵袋」の「知恵ノート」だったものを転載しています）
（最終更新日時:2016/5/23）投稿日：2012/6/12
はじめに
本ノートでは、ファイル、ファイルシステム、フォーマットについて、概観します。 コンピュータを扱うにあたって、知っておいて損は無い話です（現在９９５２字）。
ファイル
現在実用されている多くの OS では、「外部記憶や補助記憶に記録されるデータ単位」を、ファイル file と呼んでいます。
どんなに少ない・短い内容であろうと、外部記憶・補助記憶に何かを記録する時は、必ず１つ以上のファイルになります。
ファイルは、実際の内容と、付加情報をセットにしたものです。 付加情報とは、ファイルの名前、大きさや種類、作成日時などです。 これらはファイルの実内容とは直接の関わりがありません（ファイル名や拡張子を変更してもファイルの内容は変わらない）。
ファイルの実内容は、２進数値の連続です。 ですので、これを特にバイナリファイル binary file とも呼びます。
ファイルのうち、その内容が文字コード値だけから成るものを、特にテキストファイル text file ないしプレーンテキストファイル plain text file と呼びます。
（参考 https://khurata.hatenablog.com/entry/2019/04/04/050217 ）
テキストファイルには、単なるテキスト、HTML、XML、CSS、JavaScript や PHP などのスクリプト、各種プログラミング言語のソースコード、などがあります。
バイナリファイルには、実行可能ファイル、デバイスドライバ、画像ファイル、音声ファイル、動画ファイル、書庫ファイルなどがあります。
基本的に、全てのファイルはバイナリファイルなのですが、単に「バイナリファイル」と言う場合は、テキストファイル以外のファイルを指します。
なお、ある環境においてはテキストファイルであるものが、別の環境では（元々の環境における文字エンコーディングが使えないために）バイナリファイルの扱いになってしまう事は普通にあります。
フォーマット
記憶媒体（メディア media）にファイルを記録するためには、記憶媒体をフォーマットする必要があります。 名詞としてのフォーマット format は、「書式」「形式」というような意味です（履歴書のフォーマット、原稿用紙のフォーマット、など）。
HD（ハードディスク）は、磁気記録の出来る円盤ですが、製造直後の HD は単なる金属円盤であって、何をどこに、どのように磁気記録すべきかが定まっていません。 全く白紙の「自由帳」みたいなもので、「書式」がありません。 しかし、何をどこに、どのように記録すべきか分からないのでは、使い物になりません。
そこで、まず「物理フォーマット」をします。 これは、白紙のノートに、方眼紙みたいな細かい目盛りを付ける作業です。 記憶媒体の全域にわたって行うので、記憶媒体の容量が大きいほど、時間もかかります。
HD や FD（フロッピーディスク）の物理フォーマットで決まる「方眼」を、セクタ sector と呼びます。 HD の場合、１セクタは大抵 512バイトか、4096バイトですが、そうでない場合もあります。
物理フォーマットした HD 上のセクタ位置は、CHS（Cylinder Head Sector）とか、LBA（Logical Block Addressing）という方式で表します。 CHS は、ディスク装置の構成に従ってセクタの位置を決める方式で、LBA は、装置の構成に関係なく、全てのセクタに通し番号を付ける方式です。 現在は LBA が主流です。
ともあれ、物理フォーマットをして、HD の全域にセクタを敷き詰めると、HD 上の位置を「セクタ単位の通し番号」で指定出来るようになるわけです。
物理フォーマットの過程でエラー領域が見つかると、「無効セクタ（不良セクタ）」という目印が付いて、使われなくなります。 ですので、中古 HD を購入したら、いったん物理フォーマットをした方が良いでしょう。
新品 HD は、メーカーが最適な環境で物理フォーマットをしていますので、購入者が物理フォーマットをする必要はありません。 メーカーの物理フォーマットにおいても、無効セクタが出る事は有り、この場合、HD の容量は、わずかに減るわけですが、いわば液晶ディスプレイのドット抜けのようなもので、気にする必要はありません（無効セクタが一定数以上出た HD は、そもそも出荷されません）。
セクタは、フォーマットされた HD の最小利用単位です。 たった１バイトを記録するためにも、１セクタを消費します。 つまり、セクタサイズが大きいと、領域の無駄も大きくなるのですが、あまりに小さなセクタサイズだと、CHS や LBA で扱う数値、つまりセクタ位置の値が大きくなり過ぎてしまうので、512 とか 4096 という大きさに落ち着いています。
たとえば、3TB の HD におけるセクタサイズとセクタ数の関係は、次のようになります。
- セクタサイズ 512バイト → セクタ数は、3T／512＝6442450944（約 64億）
- セクタサイズ 4096バイト → セクタ数は、3T／4096＝805306368（約 8億）
32ビットでは約 43億弱までしか表せないので、32ビットシステムでは、3TB の HD 全域を 512バイト・セクタでは扱えません。 こういう事もあるので、セクタサイズは「小さい方が無駄が少なくて良い」とは、一概に言えません。
セクタを敷き詰めた HD は、ディスク上の位置を特定出来ますし、ファイルを記録する事も出来ます。 しかし、100個のファイルを記録するとして、それらを単に並べて記録していったら、100個目のファイルを探し出すためには、先頭から 99個のファイル分のセクタを読み飛ばさなければなりません。 これは無駄です。
そこで、次に「論理フォーマット」をします。 これは、方眼をどう使うかを決める作業です。 方眼紙に、日記帳っぽい罫線を引けば日記帳として使えますし、原稿用紙っぽい罫線を引けば原稿用紙として使えます。 いずれも、行とかマス目とかページ番号欄などの「管理情報」があり、それらを使えば、素早く目的の場所にたどり着けます。 １ミリ方眼の目盛りを１つずつたどるよりも、原稿用紙のマス目やページ番号をたどっていく方が、はるかに早いというわけです。
論理フォーマットをすると、ファイルを管理するための領域が確保され初期化されます。 管理領域には、ファイルの付加情報や、ファイルを HD 上から素早く探し出すための情報（後述）などが記録されます。
ですので、論理フォーマットをすると、記録可能容量は減ってしまいます。 1.5TB の HD を買ったのに 1.35TB しかない、というのは、管理領域に「食われた」のです。
論理フォーマットは、物理フォーマットに比べて、かなり短時間で終わります。 「方眼を敷き詰める」わけではないからです（クイックフォーマットは、論理フォーマットだけを行っています）。
ファイルシステム
ファイルシステム file system とは、記憶媒体に、ファイルをどう記録していくかという決まり事です。
代表的なものには、FAT、NTFS、XFS、HFS、ISO9660、UDF などがあり、それぞれに制限の違い、付加情報の違い、利点・欠点、媒体の種類についての向き・不向きがあります。
HD、CD、DVD、BD、MO、フロッピーディスク、USBメモリ、RAMディスクなどの様々なメディア……これらの記憶媒体を、NTFS で使うか、XFS で使うか、FAT で使うか、それは利用者の選択に委ねられていますが、大抵は、使用 OS で使えるファイルシステムを選ぶ事になります。 HD の場合、Windows なら FAT か NTFS、MacOS なら HFS ないし HFSX、Linux なら XFS や Ext4 等になるでしょう。
「ファイルシステムの選択」とは、「どういう論理フォーマットをするか」という事です。
先ほど、「日記帳っぽい罫線を引けば日記帳になりますし……」と書きましたが、FAT で論理フォーマットした媒体は FAT になり、NTFS で論理フォーマットした媒体は NTFS になるわけです。
（「論理フォーマット」は、フォーマットするという動詞として使われる事もあれば、ファイルシステムとほぼ同義、つまり名詞として使われる事もある言葉です）
違うファイルシステムは、互換性がありません。 MacOS でフォーマットした HFSX の HD は、素の Windows では認識すら出来ません。 Windows は「HFSX を知らない」からです（日記帳のフォーマットしか知らない者に原稿用紙を渡しても、使い方は分かりません）。
逆に考えれば、「HFSX を知っているソフト、ないしデバイスドライバ」を使えば、Windows からでも使えるようになります。
例：
http://www.e-frontier.co.jp/product/macdrive/index.html
http://www.catacombae.org/hfsx.html
似た話は、DVD-RAM やブルーレイディスクにも言えます。 Windows XP は、これらのファイルシステムである UDF を「知らない」ため、これらのディスクを認識出来ません。 そのため、UDF ドライバを別途インストールしてやる必要がありました。
対して Windows Vista／7 は、UDF ドライバを標準で内蔵したので、素で DVD-RAM やブルーレイディスクにアクセスする事が出来ます。
各 OS がそれぞれ独自のファイルシステムを「知っている」のは、それぞれのファイルシステム用のドライバないしソフトウェアを「標準で内蔵している」からなのです。
ファイルシステムへのアクセス
ファイルシステムの管理領域には、記録されている各ファイルについて、ファイル名、その有無、使用セクタの位置情報などが記録されています。
コンピュータが HD などの媒体を使う時は、ファイル名を手がかりにして、ファイルシステムの管理領域の中から該当ファイル名を探し出し、その有無や、実体の記録セクタ位置を知るところから始めます。 セクタ位置が分かれば、即座にそこへアクセス出来ます。 100個目のファイルだからといって、99個のファイルを空読みする必要はありません。
ファイルサイズがセクタサイズを越えている場合、「次のセクタ位置」がどこであるかも、管理領域に記録されています。 管理領域に記録されているセクタ位置に順番にアクセスしていけば、１つの大きなファイルの全体にアクセス出来るのです。
新しくファイルを作る時も、管理領域をまず見ます。 管理領域において「使われている」とされているセクタ以外のセクタを探し、そのセクタを「使う」と予約して（つまり管理領域にその旨を記録して）、そのセクタにファイルの内容を記録します。 この過程で、空きセクタが足りないと分かると、「ディスクがいっぱいです」という事になります。
なお、管理領域それ自体の記録位置（セクタ位置）は、ファイルシステムによって「決め打ち」されています。 従って、OS が知っているファイルシステムでなければ、ファイルにたどり着く事は出来ません。 「日記帳」しか知らない OS に「原稿用紙」を渡しても認識出来ないのです。
最初のうちは「使用済みセクタ」が先頭の方に固まり、「空きセクタ」は後ろの方に固まっていますが、ファイルを作ったり消したりしていると、使用セクタ と空きセクタが、ごちゃごちゃになっていきます。 すると、ファイルを新しく作る時に、飛び飛びの空きセクタを使わざるを得なくなります。 この様子を、（セクタの）断片化 fragmentation と呼びます。
断片化が進むと、ファイルを使う時に、飛び飛びのセクタにアクセスする事になるため、速度性能が落ちていきます。 これをキレイにするのが、デフラグ defragment です。 デフラグすると、飛び飛びになったファイルが、連続したセクタに記録し直され、速度性能が回復します。
ファイルの消去～ごみ箱の仕組み
ファイルを削除した時、もし、ファイルの中身そのものを全部消していったら、巨大なファイルを消す時、かなりの時間がかかってしまいます。 そこで、まずは管理領域の「ファイルの有無情報」だけを書き換えて、見かけ上、ファイルが有りませんよ、という事にしています。
「ごみ箱」とは、「有無情報は『無』だけれども、記録セクタ位置の情報がまだ残っているファイル」を憶えているプログラムです。 「ごみ箱」で「元に戻す」と、有無情報を「有」に書き換えてくれます。 たったこれだけで元通りです。
「ごみ箱」から削除すると、ファイルの付加情報、ファイル名と記録セクタ位置などが、ファイルシステムの管理領域から消去されます。 こうなると、もう普通の方法では復旧出来ません。 ファイル名もセクタ位置も分からないのですからお手上げです。
しかし、セクタの内容は、まだ残っています。 新しいファイルを作りさえしなければ。
全ての「使われていないとされるセクタ」を検査し、関連しそうなセクタを丹念に拾い集め、つなぎあわせれば、消したファイルを復旧できます。 そのための特殊なソフトもあり、機能によって、フリーウェアから数十万円以上するものまで、さまざまです。
復旧を避けるために、消した後に、無意味なファイルをたくさん作ったり、空きセクタに無意味な内容を何度も上書きする「完全消去」ソフトもあります。 しかし、磁気記録には「以前どういう内容だったか」が残る性質があるため（磁気ヒステリシス）、本当に完全に消去するのは難しい事もあります。
http://ja.wikipedia.org/wiki/ヒステリシス
警察や、特定のフォレンジック業者は、磁気ヒステリシスを解析する特殊な機器を持っているそうです。
階層フォルダ
多くのファイルシステムには、フォルダないしディレクトリというものがあります。 これは、フォルダ（ディレクトリ）の「中」に、ファイルやフォルダ（ディレクトリ）を格納しているように見える仕組みです。 フォルダが多段の入れ子に出来る場合、これを階層フォルダ（階層ディレクトリ）と呼びます。
この仕組みを理解するには、まずディレクトリについて知る必要があります。
ディレクトリ directory とは、「住所録」というような意味の言葉です。 ファイルシステムを使う時は、まず管理領域の中から対象のファイル名を探索する事から始まります。 つまり、ファイル毎のファイル名や使用セクタ位置が書かれた「住所録」が、管理領域に有る……という感じです。
このため、ファイルシステムの管理領域は、当初「ディレクトリ」と呼ばれていました。
初期のファイルシステムでは、ディレクトリは管理領域そのものであり、ファイルシステム１つの中に、ディレクトリは１つでした。 従って、ファイルの一覧を表示させると、単なるファイル名の羅列になりました。
しかし、ファイルを多く扱うようになると、それでは不便になってきました（１万個のファイル名が、ただ並んでいるだけだと、厳しいです）。
そこで、「ファイル達を分類して、複数の場所に振り分けて置いておければ……」という要望から、「１つのファイルシステムの中に、複数の管理領域（ディレクトリ）を置く」、という発想が出てきました。 元々の管理領域（ディレクトリ）とは別に、「子ディレクトリ」達を持つわけです。
そして、元々のディレクトリ１つを、特にルート root（根）と呼ぶ事にしました。 １つのルート・ディレクトリから、複数の子ディレクトリが、いくつか枝分かれして存在する、というイメージです。
ルートディレクトリは元々有るものですから、特に問題は無いのですが、子ディレクトリは、どう実現すれば良いでしょうか。 方法はいくつか考えられますが、１つの案は、「子ディレクトリは、ルートとは別の管理領域を持つ、特殊なファイルである」というものです。
「ごみ箱」の説明で、ファイルには、それぞれ「有無情報」がある、と書きました。 それとは別に、それぞれのファイルに、「これは子ディレクトリであるかどうか」という情報を持たせます。 そして、「これが子ディレクトリである」というファイルの実内容には、「ルートとは別の管理領域」を記録するのです。
こうすれば、「子ディレクトリである」ファイルにアクセスすれば、「ルートとは別の管理領域」に到達出来るので、その管理領域において、あらためてファイル名を探索する事が出来ます。 その管理領域にファイル名が１つも記録されていなければ、その子ディレクトリは、「空きディレクトリ」です。
このような方法を使えば、子ディレクトリに、さらに孫、ひ孫のディレクトリを持たせる事が出来ますし、ディレクトリが違えばファイル名が重なっていても構いません。 これが階層ディレクトリです。
後に、「ファイルをまとめてしまっておく事が出来る」ディレクトリを、書類をしまっておく文房具になぞらえて、フォルダ folder と呼ぶようになりました。 Windows や MacOS などの GUI OS では、「子ディレクトリであるかどうか」情報を見て、フォルダのアイコンを表示するかどうかを決めているわけです。
ファイルシステムの安全機構
今まで説明した事は、ファイルシステムの、ごく基本的な模式に過ぎません。 上記のような単純なファイルシステムでは、管理領域に不良セクタが発生すれば、それだけで媒体が使えなくなってしまいます。 また、「現在の状態」しかないので、アクセス中に突然の電源断に見舞われれば、管理領域は壊れてしまい、やはり媒体は使えなくなってしまいます。
そうした事態に備え、実際に使われているファイルシステムでは、管理領域は、複数個コピーされています。
また、現在実用されているファイルシステムの多くは、ジャーナリングという仕組みを持っています。 ジャーナル journal とは「日誌」などの意味であり、ジャーナリングは、行動記録というような意味です。
ジャーナリング・ファイルシステムでは、ファイルシステムに対するアクション、つまりファイル作成や削除、ファイル名変更、コピーなどの「操作そのもの」についても、その順番通りに、管理領域に記録します。 なおかつ、それぞれの操作が未完かどうかも、常に管理領域に持ちます。
こうしておけば、突然の障害に見舞われても、その後に「全ての未完のアクション」を「無かった事」にして、「完了したアクションしかない状態」に戻す事が出来ます。 完了アクションだけならば、管理領域内に矛盾は無いわけですから、媒体が使えなくなる事態は避けられます。
書庫ファイル
zip、rar、sit など、いわゆる圧縮書庫とか、アーカイブ archive と呼ばれるファイルがあります。 これらは、１つないし複数のファイルのサイズを可逆圧縮し、１つのファイルにまとめたものです（書庫ファイルを分割する事もありますが、書庫として使うためには、結合して１つの書庫を揃えなければなりません）。
（可逆圧縮については右記参照 https://khurata.hatenablog.com/entry/2019/04/04/045011 ）
それぞれの書庫の中には、各ファイルがどのように内部配置されているかという管理情報が格納されています。 この管理情報や、内部ファイルの格納のされ方は、zip、rar、sit 等の異なる書庫ファイルの間では、互換性がありません。
つまり、書庫ファイルの内部ファイルにアクセスするには、その書庫形式（フォーマット）を知るソフトウェアを使わねばなりません。 sit を「知らない」OS では、sit 書庫の中のファイルを見る事は出来ないのです。
こう考えると、書庫ファイルは、それ自体が１つのファイルシステムであり、一種の論理フォーマット（書式、形式）である、と言えます。
イメージファイル
「ISO ファイル」とか「ディスクイメージ」という言葉を御存知の方もいらっしゃるでしょう。 たとえば DVD の ISO とか、CD イメージとか、起動 HD イメージとか…。
これらは、「その中に、ある媒体のファイルシステムを丸ごと記録した」バイナリファイルであり、「イメージファイル」と総称されます。
「NTFS フォーマットの HD を全てコピーする」場合、「普通は」、別の HD に、そのファイルとフォルダを全てコピーするでしょう。
コピー先の HD は NTFS であっても NTFS でなくても構いません。 この HD を Mac につないで、HFSX フォーマットの HD にコピーする事も出来ます。 全てのファイルが 4GB 未満であれば、FAT32 の HD にコピーする事も出来ます。 ネットワーク越しに FTP でアップロードしたり、Samba 経由でコピーすれば、コピー先のファイルシステムは不問です。
この場合、ファイルとフォルダという形はコピーされますが、ファイルシステムに関する情報、ファイルの元々の記録セクタ位置などの情報は失われます。
もう１つのやり方は、ファイルが記録されている「有りよう」を、そっくりそのままコピーする事です。 つまり管理領域と全てのセクタをそのままコピーしてしまうのです。 コピーというより、クローンと言う方が、しっくり来るかも知れません。 こうして作られたファイルを、イメージファイルと呼びます。
イメージファイルそのものは、１つのバイナリファイルに過ぎませんが、その中には、ファイルシステムごと、媒体まるごとの情報が保持されています（もちろん、単なるバイナリファイルですから、どのファイルシステムに置いても構いませんし、可逆圧縮しても結構です）。
イメージファイルを、何らかの HD に「復元」すると、コピー元におけるファイルシステムの様子がそのまま復元され、元の使用セクタと全く同じ位置のセクタが使われて、ファイルやフォルダが配置されます。 元のセクタが断片化していれば、復元先のセクタも、全く同じように断片化します。
イメージファイルの使い方は、主に２つあります。
１つは、イメージファイルを、何らかの媒体に復元して、普通に使う事です。 イメージファイルを作成したり、復元したりするには、それ用のソフトウェアを使います。
例：
http://www.forest.impress.co.jp/lib/sys/file/syncbackup/paragonbakup.html
http://www.nihongoka.com/jpatch_dairi/todobackup/
http://www.nihongoka.com/jpatch_main/imgburn/
もう１つは、イメージファイルをマウント mount して、仮想ドライブ装置として使う事です。 イメージファイルをマウントすると、OS から見て、ディスクドライブが増えたように見えます。
この使い方は、何らかの媒体に復元する必要が無く、お手軽です。 イメージファイルをマウントするにも、それ用のソフトウェアを使います。
例：
http://www.nihongoka.com/daemontools/
http://www.free-downloads.net/programs/Alcohol_52__Free_Edition
考えようによっては、書庫ファイルは「書庫というファイルシステム」のイメージファイルである、とも言えます。
おわりに
いかがだったでしょうか。 短くはありませんが、たぶん、難しい内容は、ほとんど無かったと思います。 「分かってみれば、なんだ、そんな事だったのか」、と思っていただければ、ありがたいです。
（転載以上）
