2003とNTFSファイル・システムが必須。■FAT32ファイル・システムでは、4Gbytes超のパーティションを利用することができるが、ファイル・サイズは4Gbytesまでに制限される。■ネットワーク経由の場合は、利用できる最大ファイル・サイズは、ローカルとリモートのOSの両方の制約を受ける。■アプリケーションによっては4Gbytes超だけでなく、2Gbytes超のファイルでも操作に失敗する可能性があるので注意する。昨今では、PCでビデオをキャプチャ、編集することも一般的になってきたため、ギガバイト・クラスの巨大なファイルを取り扱う機会も増えてきている。ハードディスク自体のサイズも大きくなっているので、OS付属のバックアップ・ユーティリティなどで作成されるファイルもより巨大になっている(テープ・デバイスではなく、ファイルとしてハードディスクに保存させた場合)。バックアップすべきファイルの総容量は、圧縮機能を利用しても2Gbytesや4Gbytesを超えることも珍しくない。ファイル・システムやOSの制限によっては、扱える最大ファイル・サイズに制限があり、いくら大きなディスクを使ってもその限界を超えることはできない。OSで利用できるファイル・システムと、ファイル・サイズのそれぞれの制限についてまとめておく。ファイル・システムの制限システムで扱えるファイル・サイズの最大値(制限)を決める第一の要件は、ファイル・システムそのものに起因している。どのファイル・システムを使うかによって、利用できるパーティションの最大サイズや収容できるファイルの総サイズ、ファイルごとのサイズ制限などが決まっているのである。2003で利用可能なファイル・システムの一覧とその仕様についてまとめておく。OSで利用可能なファイル・システムとその仕様についてまとめてみた。このほかにもフロッピーディスクで使われるFAT12もあるが、ここでは取り上げない。2003でFAT32ボリュームを作成する場合は、最大32Gbytesまでという制限がある。9x/Meなどであらかじめ作成しておく必要がある。2000で利用可能なファイル・システムとしては、FAT(FAT16、FAT32)とNTFSがある(FAT12はフロッピーで使用)。7のようなユーティリティを利用すれば、FATファイル・システムなしで複数のOSを切り替えてブートすることもできる)。2003では制約が多い。■FAT16FAT16は2Gbytes(もしくは4Gbytes)以下の小さなパーティションで利用可能なファイル・システムである。2003では64Kbytesのクラスタを使って最大4Gbytesのパーティションまで作成することが可能である。4.0まではFAT32が利用できなかったため、FATといえばこのFAT16パーティションが利用されていた。NTでは、インストール時にパーティションをこのFAT16でいったんフォーマットしてから、(必要ならば)あとでNTFSにコンバートするというインストール方法を取っていたため、システム・パーティションは最大でも4Gbytesまでしか利用できないという制約があった。2003では最初からNTFSフォーマットが使われるので、このような制限はない。bytes)までなので、これを超えるような大きなファイルを作成したり利用したりするためには、次に述べるFAT32かNTFSを利用する必要がある。NTでは利用できない)。このFAT32では、クラスタを指し示すための数値フィールド(クラスタ番号)を、FAT16の16bit幅から32bit幅に拡張したため、最大で2Tbytesまでのパーティションを管理することができる。ファイルのサイズは最大でも4Gbytes(正確には0xffff_ffff)までなので(ディレクトリ・エントリ中のファイル・サイズを表すフィールドが32bit幅しかないため)、たとえパーティション・サイズが10Gbytesであったとしても、そのような大きなサイズのファイルを作成することはできない。2003環境向けのネイティブなファイル・システムとして使用される。MeからNTFSボリュームに読み書きすることはできない。Win98など)を利用すれば、これらの環境からNTFSボリュームを読み書きすることは可能である。NTFSでは、4Gbytes以上のパーティションでも問題なく利用できるし、4Gbytes以上のサイズのファイルを作成することもできる。2003環境では最も望ましいファイル・システムである(特に、ドメイン・コントローラとして運用するにはNTFSが必要。ユーザーごとの情報などを厳格に保護するためである)。9x/Meからは利用できないので、2つのOS間で共有する必要のあるパーティションをNTFSにすることはできない。2003)上のファイルをアクセスする場合は、サーバ側はどのようなファイル・システムでも構わない。実際の物理的なファイルへのアクセスはサーバ側のOSが行うが、クライアントからは論理的にしか読み書きしないからである。ファイル・サイズなどの制約に関しては、ファイルの読み書きに利用するAPIの制約がそのまま適用されるので、制約が「緩くなる」ことはない。基本的には「ローカル側のOSにおける制約」と「リモート側のOSにおける制約」の「両方」の制約を受ける。その結果、制約がより厳しくなる。9x/Meでは最大4Gbytesまでのファイルしか扱えないので(*1)、ネットワーク経由で大きなNTFSパーティションへアクセスしても、利用できる最大ファイル・サイズは4Gbytesまでである。2003マシンからアクセスしても、作成できる最大ファイル・サイズは4Gbytesに制限される。9x/Me向けのプログラムでは、4Gbytes以上のファイルを正しく扱うことができない。ファイル・サイズを表すのに、32bit(4Gbytes)しか考慮していないためである。ファイル・サイズの制限これまでに述べたように、ファイル・システムやOSの仕様には、2Gbytesや4Gbytesという各種の制限があるが、実際にはそれ以外にも、アプリケーションの内部構造に基づく制約(ある意味、これらは「仕様」ともいえる)があり、その限界いっぱいまで使えるわけではない。ここでは、それらの制約についてまとめておこう。2003の場合、理論的には、NTFSファイル・システムを使えば(ネットワーク経由でNTFS上のファイルを扱う場合もこれに含む)、4Gbytes以上のファイルを作成したり、それをエクスプローラでコピーしたりすることは可能なはずである。そこで実際にそのような大きなファイルを作成してみて、それらが正しく利用できるかどうか実験してみたので、以下にその結果をまとめておく(FAT32でも3.99Gbytesの大きさのファイルまでは利用可能)。ファイル・サイズとしては、3.99Gbytes(実際には4Gbytesより1byteだけ小さいサイズで、32bitで表現できる最大サイズのこと。bytes)と4Gbytesちょうど、5Gbytesの3種類で試してみた。テスト・ファイルは、C言語のfwrite関数を使って繰り返し書き込んで作成している。ランダムなデータを書き込んでいるのでバックアップ時にはほとんど圧縮できない。2000/XPにおける大きなファイルの扱い「空きディスク・サイズ表示」とは、エクスプローラの「ディスクの空き領域」もしくはdirコマンドの最下行に表示される「〜バイトの空き領域」という表示のことを表す。ツール]−[バックアップ]を使って、正しくバックアップできるかどうかを表している。2000では、コピーの残りが4Gbytes(の倍数)になると、残り時間表示がおかしくなる。2003では問題ない。この表から分かるとおり、エクスプローラでのサイズ表示や、コマンド・プロンプト上でのcopy/xcopyコマンドでは、4Gbytes超のファイルでも正しく扱うことができた。バックアップ・コマンドで、これらのファイルをバックアップ/リストアすることも可能であるし、ファイルにバックアップした場合に生成されるバックアップ・ファイル(.bkfファイル)が4Gbytesを超えても、正しく取り扱う(コピーする)ことができる。2000では、エクスプローラを使ったファイルのコピー(マウスを右クリックして[コピー]−[貼り付け]を実行)において、コピー時間の表示が途中でおかしくなった。5Gbytesのファイルをコピーする場合、4Gbytesで割った余り(この場合は1Gbytes分)までは正しく「コピーしています」−「残り20分」などと表示されているが、そこを過ぎると、以下のようにとてつもなく大きな残り時間が表示されるようになる。2000のエクスプローラを使ったコピー作業では、コピーの残りが4Gbytes(の倍数)に達すると、残り時間の表示がとてつもなく大きな値になる。実際には、最初に提示されたぐらいの時間でコピーは終了するようなので、気長に(!)待てばよい。2003ではこのようなこともなく、正しく残り時間はカウント・ダウンしていくようだ。これは表示だけの問題であり、コピーそのものは正しく行なわれている。2003ではこのような誤表示はなく、正しく時間が表示されているようである。実際には4Gbytesものファイルをコピーするには、場合によってはかなり時間がかかるようなので、マシンがハングアップしたと勘違いしないようにしていただきたい。これには、ハードディスクのアクセス・ランプが点滅しているかや、(ネットワーク経由の場合は)トラフィックを示すLEDが点滅しているかどうかに注意するとよいだろう。以上の例は、エクスプローラやcopy/xcopyコマンドの場合であったが、そのほかのアプリケーションが実際に4Gbytes以上のファイルを扱えるかどうかは、残念ながらやってみなければ分からないとしかいえない。標準的なC言語のライブラリでは、例えば_lseek/fseek関数(ファイルを読み書きする位置を設定するための関数)では32bit幅のオフセットしか考慮されていないので、4Gbytesを超えるファイルを扱うことはできない。9x/Meしか対象にしていないアプリケーションでは、このような対策は行われていないかもしれないからだ。これ以外にも、例えばビデオ・データを格納するために使われるAVIファイルでは、仕様上、1つのファイルで最大2Gbytesしか扱えないなど(複数のファイルに分割する拡張方式もある)、そのほかの要因も考えられるので、大きなファイルを扱いたい場合はケース・バイ・ケースで考える必要がある。9x/Meとの互換性も考慮すると、よほどの事情がないかぎり、ファイル・サイズは4Gbytesより小さくしておくのが無難だろう。9x/Meでも行ってみた。結果は以下に示すとおり、4Gbytesもしくはそれ以上のファイルを扱うことはほぼ不可能と考えてもよいであろう。95の初期バージョンでネットワーク経由のディスクの空き領域を表示させると、たとえ2Gbytes以上空いていても、常に2Gbytesと表示される)、これだけではあまり役に立つとはいえないだろう。2000のNTFS上に作成して、これをネットワーク経由でアクセスしてテストしている。9x/Meにおける大きなファイルの扱い4Gbytes以上のファイルについては、NTFS上のファイルをネットワーク経由でアクセスして実験した。ディスク空きサイズ表示とエクスプローラでのファイル・サイズ表示は正しく行えるが、それ以外のケースでは4Gbytes以上のファイルを扱うことはできない。ファイル・サイズが4Gbytes未満でも(3.99Gbytesでも)、(コマンドの内部構造のためであろうか)正しくコピーできない。安全のためには、4Gbytesよりも64Kbytes程度(できれば1Mbytes程度)小さいサイズまでにしておいた方がよいであろう。9xのようなバックアップ・コマンドが提供されていないため、テストしていない)。以上から分かるように、4Gbytes未満(3.99Gbytes)でも、コピーやバックアップなどでは操作が失敗した(もちろん、もっと小さなサイズ、例えば3Gbytesならばこれらは問題なく完了する)。これはアプリケーションの作り方に依存しているようである。これらのコマンドでは、数Kbytesから数10Kbytesを単位として読み書き動作を繰り返しているが、内部で最後のブロックを処理するときに、オフセットが4Gbytesを超えてしまうようである。これを32bitで表すと0に戻ってしまうので、ファイルの終わりが検出できなくなって無限ループに陥ったり、(0になって)いきなり処理がそこで中断してしまったりする(この結果、最後の書き込みが行われなくなる)。このような事態を避けるためには、ファイル・サイズを4Gbytesぎりぎりにするのではなく、いくらかの余裕を持ったサイズまでにしておけばよいだろう。4Gbytesよりも64Kbytes程度か、できれば1Mbytes程度小さいサイズにすれば大丈夫なようだ。万全を期すなら、ファイル・サイズを符号付き32bit数値で扱っているような(作りの悪い)プログラムにも考慮して、最大でも2Gbytesまでにしておいた方がよいかもしれない。いずれにしろ大きなファイルを扱うときは、一度実験をして、正しく操作できることを確認するようにしていただきたい(例えば、ファイルをいきなり「移動」するのではなく、まずは「コピー」をして、コピー先が正しいことを確認してから、元のファイルを「削除」する、など)。より自動抽出したものです。【2000/11/10】FAT16の説明において、当初、「FAT16はフロッピーや2Gbytes(もしくは4Gbytes)以下の小さなパーティションで利用可能なファイル・システムである」と記述しておりましたが、フロッピーで使用されているファイル・システムはFAT12でした。お詫びして訂正させていただきます。XPに関する情報追加に加え、最新情報を反映して加筆・修正しました。2003に関する情報を追加しました。Chromeでファイルをダウンロードする際の保存場所を変更する方法を紹介。Gmailに届いたメールを他のメールアドレスに転送する方法を紹介する。