[System Environment] | ||||||||||||||||||
ファイル・システムの制限―― 2G/4GBytes超のファイルに注意 ――
|
||||||||||||||||||
|
解説 |
昨今では、PCでビデオをキャプチャ、編集することも一般的になってきたため、ギガバイト・クラスの巨大なファイルを取り扱う機会も増えてきている。また、ハードディスク自体のサイズも大きくなっているので、OS付属のバックアップ・ユーティリティなどで作成されるファイルもより巨大になっている(テープ・デバイスではなく、ファイルとしてハードディスクに保存させた場合)。バックアップすべきファイルの総容量は、圧縮機能を利用しても2Gbytesや4Gbytesを超えることも珍しくない。しかしファイル・システムやOSの制限によっては、扱える最大ファイル・サイズに制限があり、いくら大きなディスクを使ってもその限界を超えることはできない。ここではWindows OSで利用できるファイル・システムと、ファイル・サイズのそれぞれの制限についてまとめておく。
ファイル・システムの制限
システムで扱えるファイル・サイズの最大値(制限)を決める第一の要件は、ファイル・システムそのものに起因している。つまり、どのファイル・システムを使うかによって、利用できるパーティションの最大サイズや収容できるファイルの総サイズ、ファイルごとのサイズ制限などが決まっているのである。次の表に、Windows 9x/2000/XP/Server 2003で利用可能なファイル・システムの一覧とその仕様についてまとめておく。
ファイル・システム | FAT16 | FAT32 | NTFS |
利用可能なOS | Windows 9x/Me/NT/2000/XP/Server 2003 | Windows 9x/Me/2000/XP/Server 2003 | Windows NT/2000/XP/Server 2003 |
ボリューム・サイズの制限 | 2Gbytes(9x/Me)もしくは4Gbytes(NT/2000/XP/Server 2003) | 2Tbytes | 2Tbytes以上 |
ファイル・サイズの制限 | 2Gbytesまで | 4Gbytesまで | ボリューム・サイズまで |
備考 | Windows NT/2000/XP/Server 2003では4Gbytesのボリューム/ファイル・サイズまで利用可能 | Windows 2000/XP/Server 2003で作成可能なFAT32ボリュームは32Gbytesまでだが、作成済みのFAT32ボリュームを利用するなら、より大きなボリューム・サイズでもよい | |
Windows OSで利用可能なファイル・システムとその仕様 | |||
各Windows OSで利用可能なファイル・システムとその仕様についてまとめてみた。このほかにもフロッピーディスクで使われるFAT12もあるが、ここでは取り上げない。Windows 2000/XP/Server 2003でFAT32ボリュームを作成する場合は、最大32Gbytesまでという制限がある。これより大きなFAT32ボリュームを利用したければ、Windows 9x/Meなどであらかじめ作成しておく必要がある。 |
Windows 2000で利用可能なファイル・システムとしては、FAT(FAT16、FAT32)とNTFSがある(FAT12はフロッピーで使用)。このうち、FAT16とFAT32はWindows 9x/Meでも利用可能なファイル・システムであるため、デュアルブート・システムでWindows 2000やWindows XPなどと共存させたりする場合には必須のファイル・システムである(ソフトボート社の販売するシステムコマンダー 7のようなユーティリティを利用すれば、FATファイル・システムなしで複数のOSを切り替えてブートすることもできる)。しかしFATファイル・システムでは、1ファイルあたりのサイズ制限があるし、NTFSで利用できるような高度なセキュリティ機能が利用できないため、Windows 2000やWindows XP、Windows Server 2003では制約が多い。
■FAT16
FAT16は2Gbytes(もしくは4Gbytes)以下の小さなパーティションで利用可能なファイル・システムである。ただしWindows 9x/Meでは、最大クラスタ・サイズは32Kbytesなので、パーティションの最大サイズは2Gbytesであるが、Windows NT/2000/XP/Server 2003では64Kbytesのクラスタを使って最大4Gbytesのパーティションまで作成することが可能である。
Windows NT 4.0まではFAT32が利用できなかったため、FATといえばこのFAT16パーティションが利用されていた。特にWindows NTでは、インストール時にパーティションをこのFAT16でいったんフォーマットしてから、(必要ならば)あとでNTFSにコンバートするというインストール方法を取っていたため、システム・パーティションは最大でも4Gbytesまでしか利用できないという制約があった。Windows 2000やWindows XP、Windows Server 2003では最初からNTFSフォーマットが使われるので、このような制限はない。
FAT16で利用可能な最大ファイル・サイズは、最大2Gbytes(正確には0x7fff_ffff bytes)までなので、これを超えるような大きなファイルを作成したり利用したりするためには、次に述べるFAT32かNTFSを利用する必要がある。
■FAT32
Windows 9x/Meだけでなく、Windows 2000やWindows XP、Windows Server 2003(さらに現在ではLinuxなどのOS)でも利用可能なため、現時点で最も汎用性の高いファイル・システムがこのFAT32である(Windows NTでは利用できない)。このFAT32では、クラスタを指し示すための数値フィールド(クラスタ番号)を、FAT16の16bit幅から32bit幅に拡張したため、最大で2Tbytesまでのパーティションを管理することができる。だがファイルのサイズは最大でも4Gbytes(正確には0xffff_ffff)までなので(ディレクトリ・エントリ中のファイル・サイズを表すフィールドが32bit幅しかないため)、たとえパーティション・サイズが10Gbytesであったとしても、そのような大きなサイズのファイルを作成することはできない。
■NTFS
NTFSはWindows NTとともに開発されたファイル・システムで、Windows NT/2000/XP/Server 2003環境向けのネイティブなファイル・システムとして使用される。NTFSボリュームを読み書きできるのはWindows NT/2000/XP/Server 2003だけであり、Windows 9xやWindows MeからNTFSボリュームに読み書きすることはできない。ただし特別なツール(WinternalsのNTFS for Win98など)を利用すれば、これらの環境からNTFSボリュームを読み書きすることは可能である。NTFSでは、4Gbytes以上のパーティションでも問題なく利用できるし、4Gbytes以上のサイズのファイルを作成することもできる。アクセス・コントロール・リスト(ACL:Access Control List)に基づいたセキュリティ機能も備えており、Windows 2000/XP/Server 2003環境では最も望ましいファイル・システムである(特に、ドメイン・コントローラとして運用するにはNTFSが必要。ユーザーごとの情報などを厳格に保護するためである)。しかし(標準では)Windows 9x/Meからは利用できないので、2つのOS間で共有する必要のあるパーティションをNTFSにすることはできない。
■ネットワーク経由のファイル・アクセス
ネットワーク経由でファイル・サーバ(Windows 9x/Me/NT/2000/XP/Server 2003)上のファイルをアクセスする場合は、サーバ側はどのようなファイル・システムでも構わない。実際の物理的なファイルへのアクセスはサーバ側のOSが行うが、クライアントからは論理的にしか読み書きしないからである。だがファイル・サイズなどの制約に関しては、ファイルの読み書きに利用するAPIの制約がそのまま適用されるので、制約が「緩くなる」ことはない。基本的には「ローカル側のOSにおける制約」と「リモート側のOSにおける制約」の「両方」の制約を受ける。その結果、制約がより厳しくなる。
例えばWindows 9x/Meでは最大4Gbytesまでのファイルしか扱えないので(*1)、ネットワーク経由で大きなNTFSパーティションへアクセスしても、利用できる最大ファイル・サイズは4Gbytesまでである。逆に、FAT32パーティションを公開しているWindows 98マシンに対して、Windows 2000/XP/Server 2003マシンからアクセスしても、作成できる最大ファイル・サイズは4Gbytesに制限される。
*1 一般的にWindows 9x/Me向けのプログラムでは、4Gbytes以上のファイルを正しく扱うことができない。ファイル・サイズを表すのに、32bit(4Gbytes)しか考慮していないためである。 |
ファイル・サイズの制限
これまでに述べたように、ファイル・システムやOSの仕様には、2Gbytesや4Gbytesという各種の制限があるが、実際にはそれ以外にも、アプリケーションの内部構造に基づく制約(ある意味、これらは「仕様」ともいえる)があり、その限界いっぱいまで使えるわけではない。ここでは、それらの制約についてまとめておこう。
■Windows NT/2000/XP/Server 2003の場合
Windows NT/2000/XP/Server 2003の場合、理論的には、NTFSファイル・システムを使えば(ネットワーク経由でNTFS上のファイルを扱う場合もこれに含む)、4Gbytes以上のファイルを作成したり、それをエクスプローラでコピーしたりすることは可能なはずである。そこで実際にそのような大きなファイルを作成してみて、それらが正しく利用できるかどうか実験してみたので、以下にその結果をまとめておく(FAT32でも3.99Gbytesの大きさのファイルまでは利用可能)。
ファイル・サイズとしては、3.99Gbytes(実際には4Gbytesより1byteだけ小さいサイズで、32bitで表現できる最大サイズのこと。16進数で表現すると0xffff_ffff bytes)と4Gbytesちょうど、5Gbytesの3種類で試してみた。テスト・ファイルは、C言語のfwrite関数を使って繰り返し書き込んで作成している。ランダムなデータを書き込んでいるのでバックアップ時にはほとんど圧縮できない。
ファイル・サイズ | 3.99Gbytes |
4Gbytes |
5Gbytes |
実際のサイズ(16進数) | 0xffff_fffff |
0x1_0000_0000 |
0x1_4000_0000 |
コマンド | |||
空きディスク・サイズ表示 | ○ |
○ |
○ |
エクスプローラの[プロパティ]メニューによるサイズ表示 | ○ |
○ |
○ |
dirコマンドでのサイズ表示 | ○ |
○ |
○ |
エクスプローラでのコピー | ○ |
○(*) |
○(*) |
copyコマンド | ○ |
○ |
○ |
xcopyコマンド | ○ |
○ |
○ |
バックアップ・コマンド | ○ |
○ |
○ |
Windows 2000/XPにおける大きなファイルの扱い | |||
「空きディスク・サイズ表示」とは、エクスプローラの「ディスクの空き領域」もしくはdirコマンドの最下行に表示される「〜バイトの空き領域」という表示のことを表す。「バックアップ・コマンド」は、[プログラム]−[アクセサリ]−[システム ツール]−[バックアップ]を使って、正しくバックアップできるかどうかを表している。 | |||
* Windows 2000では、コピーの残りが4Gbytes(の倍数)になると、残り時間表示がおかしくなる。 Windows XP/Windows Server 2003では問題ない。 |
この表から分かるとおり、エクスプローラでのサイズ表示や、コマンド・プロンプト上でのcopy/xcopyコマンドでは、4Gbytes超のファイルでも正しく扱うことができた。また、バックアップ・コマンドで、これらのファイルをバックアップ/リストアすることも可能であるし、ファイルにバックアップした場合に生成されるバックアップ・ファイル(.bkfファイル)が4Gbytesを超えても、正しく取り扱う(コピーする)ことができる。
ただしWindows 2000では、エクスプローラを使ったファイルのコピー(マウスを右クリックして[コピー]−[貼り付け]を実行)において、コピー時間の表示が途中でおかしくなった。例えば5Gbytesのファイルをコピーする場合、4Gbytesで割った余り(この場合は1Gbytes分)までは正しく「コピーしています」−「残り20分」などと表示されているが、そこを過ぎると、以下のようにとてつもなく大きな残り時間が表示されるようになる。
Windows 2000におけるコピー残り時間の誤表示 |
Windows 2000のエクスプローラを使ったコピー作業では、コピーの残りが4Gbytes(の倍数)に達すると、残り時間の表示がとてつもなく大きな値になる。しかし実際には、最初に提示されたぐらいの時間でコピーは終了するようなので、気長に(!)待てばよい。 Windows XP/Windows Server 2003ではこのようなこともなく、正しく残り時間はカウント・ダウンしていくようだ。 |
ただしこれは表示だけの問題であり、コピーそのものは正しく行なわれている。またWindows XP/Windows Server 2003ではこのような誤表示はなく、正しく時間が表示されているようである。もっとも実際には4Gbytesものファイルをコピーするには、場合によってはかなり時間がかかるようなので、マシンがハングアップしたと勘違いしないようにしていただきたい。これには、ハードディスクのアクセス・ランプが点滅しているかや、(ネットワーク経由の場合は)トラフィックを示すLEDが点滅しているかどうかに注意するとよいだろう。
以上の例は、エクスプローラやcopy/xcopyコマンドの場合であったが、そのほかのアプリケーションが実際に4Gbytes以上のファイルを扱えるかどうかは、残念ながらやってみなければ分からないとしかいえない。標準的なC言語のライブラリでは、例えば_lseek/fseek関数(ファイルを読み書きする位置を設定するための関数)では32bit幅のオフセットしか考慮されていないので、4Gbytesを超えるファイルを扱うことはできない。これに対処するためには64bit幅に対応した_lseeki64関数などを使う必要があるが、もともとWindows 9x/Meしか対象にしていないアプリケーションでは、このような対策は行われていないかもしれないからだ。
またこれ以外にも、例えばビデオ・データを格納するために使われるAVIファイルでは、仕様上、1つのファイルで最大2Gbytesしか扱えないなど(複数のファイルに分割する拡張方式もある)、そのほかの要因も考えられるので、大きなファイルを扱いたい場合はケース・バイ・ケースで考える必要がある。Windows 9x/Meとの互換性も考慮すると、よほどの事情がないかぎり、ファイル・サイズは4Gbytesより小さくしておくのが無難だろう。
■Windows 9x/Meの場合
以上と同様のテストをWindows 9x/Meでも行ってみた。結果は以下に示すとおり、4Gbytesもしくはそれ以上のファイルを扱うことはほぼ不可能と考えてもよいであろう。空き領域表示(およびエクスプローラにおけるファイル・サイズ表示)だけは正しく行えるようであるが(ただしWindows 95の初期バージョンでネットワーク経由のディスクの空き領域を表示させると、たとえ2Gbytes以上空いていても、常に2Gbytesと表示される)、これだけではあまり役に立つとはいえないだろう。なお4Gbytes以上のファイルについては、Windows 2000のNTFS上に作成して、これをネットワーク経由でアクセスしてテストしている。
ファイル・サイズ | 3.99Gbytes |
4Gbytes |
5Gbytes |
実際のサイズ(16進数) | 0xffff_ffff |
0x1_0000_0000 |
0x1_4000_0000 |
コマンド | |||
空きディスク・サイズ表示 | ○ |
○ |
○ |
エクスプローラの[プロパティ]メニューによるサイズ表示 | ○ |
○ |
○ |
dirコマンドでのサイズ表示 | ○ |
0に見える(下位32bitが0だから) | 下位32bit分しか見えない |
エクスプローラでのコピー | 失敗(サイズや内容が異なる) | 失敗(空ファイルができる) | 失敗(何もしない) |
copyコマンド | 最後の数Kbytesがコピーされない | 失敗(何もしない) | 失敗(何もしない) |
xcopyコマンド | 失敗(何もしない) | 失敗(何もしない) | 失敗(何もしない) |
バックアップ・コマンド | 失敗(途中でハングアップ*) | 失敗(*) | 失敗(*) |
Windows 9x/Meにおける大きなファイルの扱い | |||
4Gbytes以上のファイルについては、NTFS上のファイルをネットワーク経由でアクセスして実験した。ディスク空きサイズ表示とエクスプローラでのファイル・サイズ表示は正しく行えるが、それ以外のケースでは4Gbytes以上のファイルを扱うことはできない。またファイル・サイズが4Gbytes未満でも(3.99Gbytesでも)、(コマンドの内部構造のためであろうか)正しくコピーできない。安全のためには、4Gbytesよりも64Kbytes程度(できれば1Mbytes程度)小さいサイズまでにしておいた方がよいであろう。 | |||
*バックアップする元のファイルが4Gbytesちょうどだと取り扱えないし、最終的に生成されるファイルが4Gbytesを超えてもいけない(注:Windows Meでは、Windows 9xのようなバックアップ・コマンドが提供されていないため、テストしていない)。 |
以上から分かるように、4Gbytes未満(3.99Gbytes)でも、コピーやバックアップなどでは操作が失敗した(もちろん、もっと小さなサイズ、例えば3Gbytesならばこれらは問題なく完了する)。これはアプリケーションの作り方に依存しているようである。これらのコマンドでは、数Kbytesから数10Kbytesを単位として読み書き動作を繰り返しているが、内部で最後のブロックを処理するときに、オフセットが4Gbytesを超えてしまうようである。これを32bitで表すと0に戻ってしまうので、ファイルの終わりが検出できなくなって無限ループに陥ったり、(0になって)いきなり処理がそこで中断してしまったりする(この結果、最後の書き込みが行われなくなる)。
このような事態を避けるためには、ファイル・サイズを4Gbytesぎりぎりにするのではなく、いくらかの余裕を持ったサイズまでにしておけばよいだろう。例えば、4Gbytesよりも64Kbytes程度か、できれば1Mbytes程度小さいサイズにすれば大丈夫なようだ。さらに万全を期すなら、ファイル・サイズを符号付き32bit数値で扱っているような(作りの悪い)プログラムにも考慮して、最大でも2Gbytesまでにしておいた方がよいかもしれない。いずれにしろ大きなファイルを扱うときは、一度実験をして、正しく操作できることを確認するようにしていただきたい(例えば、ファイルをいきなり「移動」するのではなく、まずは「コピー」をして、コピー先が正しいことを確認してから、元のファイルを「削除」する、など)。
関連記事(Windows Server Insider) | ||
Windows TIPS:巨大なサイズのファイルを簡単に作る方法 | ||
関連リンク | ||
システムコマンダー 7(ソフトボート) | ||
NTFS for Win98(米Winternals) | ||
この記事と関連性の高い別の記事
- Windowsで巨大なサイズのファイルを簡単に作る方法(TIPS)
- デュアルブート・システムにおけるWindows 2000/XPの削除方法(TIPS)
- 32bitクライアントOSで利用できる物理メモリは最大4Gbytesまで(TIPS)
- FAT→NTFSにファイル・システムを変換する(TIPS)
- デュアルブート・システムにおけるWindows 9x/Meの削除方法(TIPS)
このリストは、デジタルアドバンテージが開発した自動関連記事探索システム Jigsaw(ジグソー) により自動抽出したものです。
更新履歴 | |||
|
「Windows TIPS」 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|