CreateFileW 関数 (fileapi.h)
ファイルまたは I/O デバイスを作成または開きます。 最も一般的に使用される I/O デバイスは、ファイル、ファイル ストリーム、ディレクトリ、物理ディスク、ボリューム、コンソール バッファー、テープ ドライブ、通信リソース、mailslot、パイプです。 この関数は、ファイルまたはデバイス、および指定されたフラグと属性に応じて、さまざまな種類の I/O のファイルまたはデバイスにアクセスするために使用できるハンドルを返します。
この操作をトランザクション操作として実行し、トランザクション I/O に使用できるハンドルを作成するには、CreateFileTransacted 関数を使用します。
構文
HANDLE CreateFileW(
[in] LPCWSTR lpFileName,
[in] DWORD dwDesiredAccess,
[in] DWORD dwShareMode,
[in, optional] LPSECURITY_ATTRIBUTES lpSecurityAttributes,
[in] DWORD dwCreationDisposition,
[in] DWORD dwFlagsAndAttributes,
[in, optional] HANDLE hTemplateFile
);
パラメーター
[in] lpFileName
作成または開くファイルまたはデバイスの名前。 この名前にはスラッシュ (/) または円記号 (\) を使用できます。
特殊なデバイス名の詳細については、「MS-DOS デバイス名の定義」を参照してください。
ファイル ストリームを作成するには、ファイルの名前、コロン、ストリームの名前を指定します。 詳細については、「ファイル ストリームの」を参照してください。
既定では、名前はMAX_PATH文字に制限されています。 この制限を 32,767 文字のワイド文字に拡張するには、パスの先頭に "\\?\" を付けます。 詳細については、「ファイル、パス、および名前空間の名前付け
先端
Windows 10 バージョン 1607 以降では、事前に "\\?\" なしでMAX_PATHの制限を削除することをオプトインできます。 詳細については、「名前付けファイル、パス、および名前空間の」の「パスの最大長制限」セクションを参照してください。
[in] dwDesiredAccess
ファイルまたはデバイスへの要求されたアクセス。読み取り、書き込み、両方、またはゼロとして要約できます)。
最も一般的に使用される値は、GENERIC_READ、GENERIC_WRITE、またはその両方 (GENERIC_READ | GENERIC_WRITE) です。 詳細については、「汎用アクセス権
このパラメーターが 0 の場合、アプリケーションは、そのファイルまたはデバイスにアクセスしなくても、ファイル、ディレクトリ、デバイス属性などの特定のメタデータ GENERIC_READ クエリを実行できます。
既に開いているハンドルを持つオープン要求で、dwShareMode パラメーターで指定された共有モードと競合するアクセス モードを要求することはできません。
詳細については、このトピックの「解説」セクションと ファイルの作成と開くを参照してください。
[in] dwShareMode
ファイルまたはデバイスの要求された共有モード。読み取り、書き込み、両方、削除、これらすべて、またはなしを指定できます (次の表を参照)。 属性または拡張属性へのアクセス要求は、このフラグの影響を受けません。
このパラメーターが 0 で、CreateFile
開いているハンドルを持つ既存の要求で指定されているアクセス モードと競合する共有モードを要求することはできません。 CreateFile は失敗し、GetLastError 関数は ERROR_SHARING_VIOLATIONを返します。
別のプロセスがファイルまたはデバイスを開いている間にプロセスでファイルまたはデバイスを共有できるようにするには、次の値の 1 つ以上の互換性のある組み合わせを使用します。 このパラメーターと dwDesiredAccess パラメーターの有効な組み合わせの詳細については、「ファイルの作成と開く」を参照してください。
[in, optional] lpSecurityAttributes
2 つの独立した関連するデータ メンバーを含む SECURITY_ATTRIBUTES 構造体へのポインター。省略可能なセキュリティ記述子と、返されたハンドルを子プロセスで継承できるかどうかを決定するブール値。
このパラメーターは NULL
このパラメーターが NULL
構造体の lpSecurityDescriptor メンバーは、ファイルまたはデバイスの SECURITY_DESCRIPTOR を指定します。 このメンバーが NULL
CreateFile は、既存のファイルまたはデバイスを開くときに lpSecurityDescriptor メンバーを無視しますが、bInheritHandle メンバーを引き続き使用します。
構造体の bInheritHandle メンバーは、返されたハンドルを継承できるかどうかを指定します。
詳細については、「解説」セクションを参照してください。
[in] dwCreationDisposition
存在する、または存在しないファイルまたはデバイスに対して実行するアクション。
ファイル以外のデバイスの場合、通常、このパラメーターは OPEN_EXISTINGに設定されます。
詳細については、「解説」セクションを参照してください。
このパラメーターは、組み合わせることができない次のいずれかの値である必要があります。
[in] dwFlagsAndAttributes
ファイルまたはデバイスの属性とフラグ FILE_ATTRIBUTE_NORMAL、ファイルの最も一般的な既定値です。
このパラメーターには、使用可能なファイル属性 (FILE_ATTRIBUTE_*) の任意の組み合わせを含めることができます。 その他のすべてのファイル属性は、FILE_ATTRIBUTE_NORMALをオーバーライドします。
このパラメーターには、ファイルまたはデバイスのキャッシュ動作、アクセス モード、およびその他の特殊な目的のフラグを制御するためのフラグ (FILE_FLAG_) の組み合わせを含めることもできます。 これらは、任意の FILE_ATTRIBUTE_ 値と結合されます。
このパラメーターには、SECURITY_SQOS_PRESENT フラグを指定することで、サービス品質 (SQOS) 情報を含めることもできます。 その他の SQOS 関連のフラグ情報は、属性およびフラグ テーブルの後の表に示されています。
ファイル属性への高度なアクセスについては、「SetFileAttributes
| 属性 | 意味 |
|---|---|
|
ファイルはアーカイブする必要があります。 アプリケーションでは、この属性を使用して、バックアップまたは削除のためにファイルをマークします。 |
|
ファイルまたはディレクトリは暗号化されます。 ファイルの場合、これはファイル内のすべてのデータが暗号化されることを意味します。 ディレクトリの場合は、暗号化が新しく作成されたファイルとサブディレクトリの既定値であることを意味します。 詳細については、「File Encryption」を参照してください。
FILE_ATTRIBUTE_SYSTEM も指定されている場合、このフラグは無効です。 このフラグは、Windows の Home、Home Premium、Starter、または ARM エディションではサポートされていません。 |
|
ファイルは非表示になっています。 通常のディレクトリ 一覧には含めないでください。 |
|
ファイルに他の属性が設定されていません。 この属性は、単独で使用する場合にのみ有効です。 |
|
ファイルのデータはすぐには使用できません。 この属性は、ファイル データがオフライン ストレージに物理的に移動されることを示します。 この属性は、階層型ストレージ管理ソフトウェアであるリモート ストレージによって使用されます。 アプリケーションでは、この属性を任意に変更しないでください。 |
|
ファイルは読み取り専用です。 アプリケーションはファイルを読み取ることができますが、書き込みや削除はできません。 |
|
ファイルは、オペレーティング システムの一部であるか、オペレーティング システムによって排他的に使用されます。 |
|
ファイルは一時ストレージに使用されています。
詳細については、このトピックの「キャッシュ動作」セクションを参照してください。 |
| 旗 | 意味 |
|---|---|
|
バックアップ操作または復元操作のためにファイルが開かれているか、作成されています。 システムは、プロセスが SE_BACKUP_NAME および SE_RESTORE_NAME 特権を持っている場合に、呼び出し元のプロセスがファイル セキュリティ チェックをオーバーライドすることを保証します。 詳細については、「トークンでの権限の変更 ディレクトリへのハンドルを取得するには、このフラグを設定する必要があります。 ディレクトリ ハンドルは、ファイル ハンドルではなく一部の関数に渡すことができます。 詳細については、「解説」セクションを参照してください。 |
|
ファイルは、指定されたハンドルとその他の開いているハンドルまたは重複するハンドルを含む、すべてのハンドルが閉じられた直後に削除されます。
ファイルに対して開いているハンドルが存在する場合、FILE_SHARE_DELETE 共有モードですべて開かなければ、呼び出しは失敗します。 FILE_SHARE_DELETE 共有モードが指定されていない限り、ファイルに対する後続のオープン要求は失敗します。 |
|
ファイルまたはデバイスは、データの読み取りと書き込みのシステム キャッシュなしで開かれています。 このフラグは、ハード ディスク のキャッシュやメモリ マップされたファイルには影響しません。
|
|
ファイル データは要求されますが、引き続きリモート ストレージに配置する必要があります。 ローカル ストレージに転送しないでください。 このフラグは、リモート・ストレージ・システムで使用するために使用されます。 |
|
通常 このフラグは、CREATE_ALWAYS フラグと共に使用することはできません。 ファイルが再解析ポイントでない場合、このフラグは無視されます。 詳細については、「解説」セクションを参照してください。 |
|
非同期 I/O 用にファイルまたはデバイスが開かれているか、作成されています。
このハンドルで後続の I/O 操作が完了すると、OVERLAPPED 構造体で指定されたイベントがシグナル状態に設定されます。 このフラグを指定すると、ファイルを読み取りと書き込みの同時操作に使用できます。 このフラグが指定されていない場合、読み取りおよび書き込み関数の呼び出しで OVERLAPPED 構造体が指定されている場合でも、I/O 操作がシリアル化されます。 このフラグで作成されたファイル ハンドルを使用する場合の考慮事項については、このトピックの「同期および非同期 I/O ハンドル |
|
アクセスは POSIX 規則に従って行われます。 これには、名前付けをサポートするファイル システムの場合にのみ異なる名前を持つ複数のファイルを許可することが含まれます。 このフラグで作成されたファイルは、MS-DOS または 16 ビット Windows 用に書き込まれたアプリケーションではアクセスできない可能性があるため、このオプションを使用する場合は注意が必要です。 |
|
アクセスはランダムであることを意図しています。 システムは、ファイル キャッシュを最適化するためのヒントとしてこれを使用できます。
このフラグは、ファイル システムがキャッシュされた I/O と FILE_FLAG_NO_BUFFERINGをサポートしていない場合は影響を与えません。 詳細については、このトピックの「キャッシュ動作」セクションを参照してください。 |
|
ファイルまたはデバイスがセッション認識で開かれています。 このフラグが指定されていない場合、セッション 0 で実行されているプロセスによってセッションごとのデバイス (RemoteFX USB リダイレクトを使用するデバイスなど) を開くことができません。
このフラグは、セッション 0 に含まれていない呼び出し元には影響しません。 このフラグは、Windows のサーバー エディションでのみサポートされます。
Windows Server 2008 R2 および Windows Server 2008: このフラグは、Windows Server 2012 より前にはサポートされていません。 |
|
アクセスは、最初から最後まで順番に行われます。 システムは、ファイル キャッシュを最適化するためのヒントとしてこれを使用できます。
このフラグは、読み取りビハインド (逆引きスキャン) を使用する場合は使用しないでください。 このフラグは、ファイル システムがキャッシュされた I/O と FILE_FLAG_NO_BUFFERINGをサポートしていない場合は影響を与えません。 詳細については、このトピックの「キャッシュ動作」セクションを参照してください。 |
|
書き込み操作は中間キャッシュを経由せず、ディスクに直接移動します。
詳細については、このトピックの「キャッシュ動作 |
dwFlagsAndAttributes パラメーターでは、SQOS 情報を指定することもできます。 詳細については、「偽装レベルの」を参照してください。 呼び出し元のアプリケーションが dwFlagsAndAttributesの一部として
[in, optional] hTemplateFile
GENERIC_READ アクセス権を持つテンプレート ファイルへの有効なハンドル。 テンプレート ファイルは、作成されるファイルのファイル属性と拡張属性を提供します。
このパラメーターは NULL
既存のファイルを開くと、CreateFile
新しい暗号化されたファイルを開くと、ファイルは親ディレクトリから随意アクセス制御リストを継承します。 詳細については、「File Encryption」を参照してください。
戻り値
関数が成功した場合、戻り値は、指定されたファイル、デバイス、名前付きパイプ、またはメール スロットへの開いているハンドルです。
失敗した場合の戻り値は、INVALID_HANDLE_VALUE です。 拡張エラー情報を取得するには、GetLastError
備考
CreateFile は、もともとはファイル操作専用に開発されましたが、その後、Windows 開発者が使用できる他のほとんどの種類の I/O デバイスとメカニズムを含むように拡張および強化されています。 このセクションでは、CreateFile をさまざまなコンテキストやさまざまな I/O の種類で使用する場合に、開発者が経験する可能性があるさまざまな問題について説明します。 テキストは、ファイル システム上の実際のファイルに格納されているデータを特に参照する場合にのみ、ファイル という単語の使用を試みます。 ただし、ファイル の一部の使用は、ファイルのようなメカニズムをサポートする I/O オブジェクトをより一般的に参照している可能性があります。 ファイル
CreateFileによって返されるオブジェクト ハンドル
Windows Server 2003 および Windows XP: dwDesiredAccess パラメーターの値が DELETE アクセス フラグ (0x00010000) または他のアクセス フラグで 'ed' である場合に、リモート コンピューターでファイルまたはディレクトリを開こうとした場合、共有違反が発生します。 リモート ファイルまたはディレクトリが FILE_SHARE_DELETEで開いていません。 このシナリオで共有違反を回避するには、
NTFS ファイル システムなどの一部のファイル システムでは、個々のファイルとディレクトリの圧縮または暗号化がサポートされています。 このサポートを持つマウントされたファイル システムを持つボリュームでは、新しいファイルは、そのディレクトリの圧縮属性と暗号化属性を継承します。
CreateFile を使用して、ファイルまたはディレクトリの圧縮、展開、または復号化を制御することはできません。 詳細については、「ファイルの作成と開き
前述のように、
bInheritHandle メンバー変数が FALSE(0 以外の値)されていない場合は、ハンドルを継承できます。 したがって、ハンドルを継承できない場合は、FALSE を するためにこの構造体メンバーを適切に初期化することが重要です。 - ファイルまたはディレクトリの既定のセキュリティ記述子のアクセス制御リスト (ACL) は、親ディレクトリから継承されます。
- ターゲット ファイル システムは、
lpSecurityDescriptor メンバーがそれらに影響を与えるために、ファイルとディレクトリのセキュリティをサポートする必要があります。これは、GetVolumeInformation使用して決定できます。
| テクノロジー | サポート |
|---|---|
| サーバー メッセージ ブロック (SMB) 3.0 プロトコル | はい |
| SMB 3.0 透過的フェールオーバー (TFO) | 解説を参照する |
| SMB 3.0 とスケールアウト ファイル共有 (SO) | 解説を参照する |
| クラスター共有ボリューム ファイル システム (CsvFS) | はい |
| 回復性のあるファイル システム (ReFS) | はい |
既に開いている代替データ ストリームがあるファイルで実行した場合、置き換え処理を含む CreateFile
シンボリック リンクの動作の
この関数の呼び出しによってファイルが作成された場合、動作に変更はありません。 また、FILE_FLAG_OPEN_REPARSE_POINTに関する次の情報も考慮してください。-
FILE_FLAG_OPEN_REPARSE_POINT が指定されている場合:
- 既存のファイルが開き、シンボリック リンクである場合、返されるハンドルはシンボリック リンクへのハンドルです。
- TRUNCATE_EXISTING または FILE_FLAG_DELETE_ON_CLOSE が指定されている場合、影響を受けるファイルはシンボリック リンクです。
-
FILE_FLAG_OPEN_REPARSE_POINT が指定されていない場合:
- 既存のファイルが開き、それがシンボリック リンクである場合、返されるハンドルはターゲットへのハンドルです。
- CREATE_ALWAYS、TRUNCATE_EXISTING、または FILE_FLAG_DELETE_ON_CLOSE が指定されている場合、影響を受けるファイルがターゲットです。
キャッシュの動作
- FILE_FLAG_NO_BUFFERING
- FILE_FLAG_RANDOM_ACCESS
- FILE_FLAG_SEQUENTIAL_SCAN
- FILE_FLAG_WRITE_THROUGH
- FILE_ATTRIBUTE_TEMPORARY
これらのフラグの一部を組み合わせてはいけません。 たとえば、FILE_FLAG_RANDOM_ACCESS と FILE_FLAG_SEQUENTIAL_SCAN を組み合わせることは自負です。
FILE_FLAG_SEQUENTIAL_SCAN フラグを指定すると、シーケンシャル アクセスを使用して大きなファイルを読み取るアプリケーションのパフォーマンスが向上する可能性があります。 大きなファイルをほぼ順番に読み取るアプリケーションでは、パフォーマンスの向上がさらに顕著になりますが、場合によっては小さなバイト範囲をスキップします。 アプリケーションがランダム アクセスのためにファイル ポインターを移動した場合、最適なキャッシュ パフォーマンスは発生しない可能性が最も高くなります。 ただし、正しい操作は引き続き保証されます。
フラグ FILE_FLAG_WRITE_THROUGH と FILE_FLAG_NO_BUFFERING は独立しており、組み合わせることができます。
FILE_FLAG_WRITE_THROUGH を使用しても FILE_FLAG_NO_BUFFERING も指定されていないため、システム キャッシュが有効な場合、データはシステム キャッシュに書き込まれますが、遅延なくディスクにフラッシュされます。
システム キャッシュが有効でないように、FILE_FLAG_WRITE_THROUGH と FILE_FLAG_NO_BUFFERING の両方が指定されている場合、データは Windows システム キャッシュを経由せずにすぐにディスクにフラッシュされます。 オペレーティング システムは、ハード ディスクのローカル ハードウェア キャッシュの書き込みスルーを永続メディアに要求します。
FILE_FLAG_WRITE_THROUGH を介した書き込み要求では、要求の処理に起因するメタデータの変更 (タイム スタンプの更新や名前変更操作など) も NTFS によってフラッシュされます。 このため、FILE_FLAG_WRITE_THROUGH フラグは、各書き込み後に FlushFileBuffers 関数を呼び出すための代わりに、FILE_FLAG_NO_BUFFERING フラグと共に使用されることが多く、不要なパフォーマンスの低下を引き起こす可能性があります。 これらのフラグを一緒に使用すると、これらのペナルティが回避されます。 ファイルとメタデータのキャッシュに関する一般的な情報については、「ファイル キャッシュの」を参照してください。
FILE_FLAG_NO_BUFFERING を FILE_FLAG_OVERLAPPEDと組み合わせると、I/O はメモリ マネージャーの同期操作に依存しないため、フラグによって最大の非同期パフォーマンスが得られます。 ただし、データがキャッシュに保持されていないため、一部の I/O 操作には時間がかかります。 また、ファイル メタデータはキャッシュされる場合もあります (空のファイルを作成する場合など)。 メタデータがディスクにフラッシュされるようにするには、FlushFileBuffers 関数を使用します。
FILE_ATTRIBUTE_TEMPORARY 属性を指定すると、ハンドルを閉じた後にアプリケーションが一時ファイルを削除するため、十分なキャッシュ メモリが使用可能な場合、ファイル システムは大容量ストレージへのデータの書き戻しを回避します。 その場合、システムはデータの書き込みを完全に回避できます。 前述のフラグと同じ方法でデータ キャッシュを直接制御することはありませんが、FILE_ATTRIBUTE_TEMPORARY 属性は、書き込まずにシステム キャッシュにできるだけ多くを保持するようにシステムに指示するため、特定のアプリケーションにとって問題になる可能性があります。
ファイル
ファイルの名前を変更または削除し、その後すぐに復元すると、システムはキャッシュで復元するファイル情報を検索します。 キャッシュされた情報には、短い名前と長い名前のペアと作成時間が含まれます。DeleteFile
dwDesiredAccess パラメーターは 0 にすることができ、アプリケーションが適切なセキュリティ設定で実行されている場合、アプリケーションはファイルにアクセスせずにファイル属性を照会できます。 これは、読み取り/書き込みアクセスのためにファイルを開かずにファイルの存在をテストしたり、ファイルまたはディレクトリに関するその他の統計情報を取得したりする場合に便利です。 GetFileInformationByHandle および
CREATE_ALWAYS と FILE_ATTRIBUTE_NORMAL が指定されている場合、CreateFile は失敗し、ファイルが存在し、FILE_ATTRIBUTE_HIDDEN 属性または FILE_ATTRIBUTE_SYSTEM 属性がある場合は、最後のエラーを ERROR_ACCESS_DENIED に設定します。 このエラーを回避するには、既存のファイルと同じ属性を指定します。
アプリケーションがネットワーク経由でファイルを作成する場合は、
詳細については、「ファイルの作成と開く」を参照してください。
同期および非同期 I/O ハンドルの
CreateFile では、同期または非同期のファイル またはデバイス ハンドルを作成できます。 同期ハンドルは、そのハンドルを使用する I/O 関数呼び出しが完了するまでブロックされるように動作しますが、非同期ファイル ハンドルを使用すると、I/O 操作が完了したかどうかにかかわらず、システムは I/O 関数呼び出しからすぐに戻ることができます。 前述のように、この同期動作と非同期動作は、dwFlagsAndAttributes パラメーター内で FILE_FLAG_OVERLAPPED を指定することによって決定されます。 非同期 I/O を使用する場合、いくつかの複雑さと潜在的な落とし穴があります。詳細については、同期および非同期 I/Oを参照してください。ファイル ストリーム
NTFS ファイル システムでは、CreateFile を使用して、ファイル内に個別のストリームを作成できます。 詳細については、「ファイル ストリームの」を参照してください。ディレクトリ
アプリケーションは CreateFileCreateFile
CreateFile を使用して FAT または FAT32 ファイル システム ボリュームの最適化中にディレクトリを開く場合は、MAXIMUM_ALLOWED アクセス権を指定しないでください。 この操作を行うと、ディレクトリへのアクセスが拒否されます。 代わりに、GENERIC_READ アクセス権を指定します。
詳細については、「ディレクトリ管理について」を参照してください。
物理ディスクとボリュームの
ディスクまたはボリュームへの直接アクセスは制限されます。Windows Server 2003 および Windows XP: ディスクまたはボリュームへの直接アクセスは、この方法では制限されません。
CreateFile 関数を使用して、物理ディスク ドライブまたはボリュームを開くことができます。このボリュームは、DeviceIoControl 関数で使用できる直接アクセス 記憶装置 (RSS) ハンドルを返します。 これにより、パーティション テーブルなどのディスク メタデータなど、ディスクまたはボリュームに直接アクセスできます。 ただし、この種類のアクセスでは、ディスク ドライブまたはボリュームのデータ損失の可能性もあります。このメカニズムを使用したディスクへの書き込みが正しくないと、その内容がオペレーティング システムからアクセスできなくなる可能性があるためです。 データの整合性を確保するには、DeviceIoControl と、ファイル システム ハンドルではなく直接アクセス ハンドルを使用して他の API がどのように動作するかについて理解しておく必要があります。
このような呼び出しを成功させるには、次の要件を満たす必要があります。
- 呼び出し元には管理者特権が必要です。 詳細については、「特別な特権を使用した実行 」を参照してください。
- dwCreationDisposition パラメーターには、OPEN_EXISTING フラグが必要です。
- ボリュームまたはフロッピー ディスクを開く場合は、dwShareMode パラメーターに FILE_SHARE_WRITE フラグが必要です。
| 糸 | 意味 |
|---|---|
| "\\.\PhysicalDrive0" | 最初の物理ドライブを開きます。 |
| "\\.\PhysicalDrive2" | 3 番目の物理ドライブを開きます。 |
ボリュームの物理ドライブ識別子を取得するには、ボリュームのハンドルを開き、DeviceIoControl 関数を IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTSで呼び出します。 この制御コードは、ボリュームの 1 つ以上のエクステントごとにディスク番号とオフセットを返します。ボリュームは複数の物理ディスクにまたがる場合があります。
物理ドライブを開く例については、「DeviceIoControlの呼び出し」を参照してください。
ボリュームまたはリムーバブル メディア ドライブ (フロッピー ディスク ドライブやフラッシュ メモリサム ドライブなど) を開く場合、lpFileName 文字列
| 糸 | 意味 |
|---|---|
| "\\.\A:" | フロッピー ディスク ドライブ A を開きます。 |
| "\\.\C:" | C: ボリュームを開きます。 |
| "\\.\C:\" | C: ボリュームのファイル システムを開きます。 |
ボリューム名を参照してボリュームを開くこともできます。 詳細については、「ボリュームの名前付け
ボリュームには、1 つ以上のマウントされたファイル システムが含まれています。 ボリューム ハンドルは、キャッシュされていないオプションが CreateFileで指定されていない場合でも、特定のファイル システムの判断でキャッシュされていないとして開くことができます
ファイル システムでは、データがキャッシュされていない場合でも、バッファーの配置が必要な場合と必要ない場合があります。 ただし、ボリュームを開くときにキャッシュされていないオプションが指定されている場合は、ボリューム上のファイル システムに関係なく、バッファーの配置が適用されます。 ボリューム ハンドルをキャッシュなしとして開き、キャッシュされていない I/O 制限に従うすべてのファイル システムで推奨されます。
チェンジャー デバイス
DeviceIoControl の IOCTL_CHANGER_* コントロール コード、チェンジャー デバイスへのハンドルを受け入れます。 チェンジャー デバイスを開くには、"\\.\Changerx" という形式のファイル名を使用します。ここで、x は、ゼロから始まる、開くデバイスを示す数値です。 C または C++ で記述されたアプリケーションで changer デバイス 0 を開くには、"\\\\.\\Changer0" というファイル名を使用します。テープ ドライブ
"\\.\TAPEx" という形式のファイル名を使用して、テープ ドライブを開くことができます。ここで、x は、テープ ドライブ 0 から始まる、開くドライブを示す番号です。 C または C++ で記述されたアプリケーションでテープ ドライブ 0 を開くには、"\\\\.\\TAPE0" というファイル名を使用します。詳細については、「バックアップ
通信リソース
CreateFile 関数は、シリアル ポート COM1 などの通信リソースへのハンドルを作成できます。 通信リソースの場合、9 より大きい COM ポート番号を指定するには、"\.\COM10" という構文を使用します。 この構文は、COM ポート番号を指定できるすべてのポート番号とハードウェアに対して機能します。
コンソール
CreateFile 関数は、コンソール入力 (CONIN$) へのハンドルを作成できます。 継承または重複の結果としてプロセスに開いているハンドルがある場合は、アクティブな画面バッファー (CONOUT$) へのハンドルを作成することもできます。 呼び出し元のプロセスは、継承されたコンソールにアタッチするか、AllocConsole 関数によって割り当てられている必要があります。 コンソール ハンドルの場合は、次のように CreateFile パラメーターを設定します。| パラメーター | 価値 |
|---|---|
| lpFileName |
CONIN$ 値を使用してコンソール入力を指定します。
CONOUT$ 値を使用してコンソール出力を指定します。 CONIN$ は、SetStdHandle 関数が標準入力ハンドルをリダイレクトした場合でも、コンソール入力バッファーへのハンドルを取得します。 標準入力ハンドルを取得するには、GetStdHandle 関数を使用します。 CONOUT$ は、SetStdHandle が標準出力ハンドルをリダイレクト |
|
dwDesiredAccess を |
GENERIC_READ | GENERIC_WRITE をお勧めしますが、どちらか一方がアクセスを制限できます。
|
|
dwShareMode を |
CONIN$ を開くときに、FILE_SHARE_READを指定します。 CONOUT$ を開く場合は、FILE_SHARE_WRITEを指定します。
呼び出し元のプロセスがコンソールを継承する場合、または子プロセスがコンソールにアクセスできる必要がある場合は、このパラメーターを |
|
lpSecurityAttributes を |
本体を継承する場合は、 |
|
dwCreationDisposition の |
CreateFile を使用してコンソールを開く場合は、 |
|
dwFlagsAndAttributes を |
無視。 |
|
hTemplateFile の |
無視。 |
次の表に、
| lpFileName | dwDesiredAccess を |
結果 |
|---|---|---|
| "CON" | GENERIC_READ | 入力用のコンソールを開きます。 |
| "CON" | GENERIC_WRITE | 出力用のコンソールを開きます。 |
| "CON" | GENERIC_READ | GENERIC_WRITE |
CreateFile |
Mailslots
CreateFile詳細については、「Mailslots」を参照してください。
パイプ
CreateFileこの操作の前に
アクティブなパイプ インスタンスが少なくとも 1 つ存在するが、サーバー上に使用可能なリスナー パイプがない場合、つまり、すべてのパイプ インスタンスが現在接続されていることを意味 、CreateFile は ERROR_PIPE_BUSYで失敗します。
詳細については、「パイプ」を参照してください。
例
ファイル操作の例を次のトピックに示します。
- 1 つのファイルを別のファイルに追加する
-
保留中の I/O 操作 を取り消す
- リダイレクトされた入出力 を使用した子プロセスの作成
- 一時ファイル の作成と使用
- FSCTL_RECALL_FILE
-
GetFinalPathNameByHandle を
する -
ファイル のバイト範囲のロックとロック解除の
-
ファイル ハンドル からファイル名を取得する
-
ファイル システム認識情報の取得 の
-
の読み取りまたは書き込みのためにファイルを開く
- Last-Write 時間 の取得
-
SetFileInformationByHandle の
-
ファイル の末尾のテストを
する -
ファイバー を使用した
-
ストリーム を使用した
- 変更履歴レコードのバッファーを歩く
- Wow64DisableWow64FsRedirection
- Wow64EnableWow64FsRedirection
-
DeviceIoControl を呼び出す
- 通信リソース の構成
-
通信イベントの監視 の
-
デバイス を削除する要求の処理を
する
mailslot の操作は、mailslotへの書き込みの
テープ バックアップ コード スニペットは、バックアップ アプリケーションの作成
手記
fileapi.h ヘッダーは、Unicode プリプロセッサ定数の定義に基づいて、この関数の ANSI または Unicode バージョンを自動的に選択するエイリアスとして CreateFile を定義します。 エンコードに依存しないエイリアスをエンコードに依存しないコードと組み合わせて使用すると、コンパイルエラーやランタイム エラーが発生する不一致が発生する可能性があります。 詳細については、「関数プロトタイプの 規則」を参照してください。
必要条件
| 要件 | 価値 |
|---|---|
| サポートされる最小クライアント | Windows XP [デスクトップ アプリのみ] |
| サポートされる最小サーバー | Windows Server 2003 [デスクトップ アプリのみ] |
| ターゲット プラットフォーム の |
ウィンドウズ |
| ヘッダー | fileapi.h (Windows.h を含む) |
| ライブラリ | Kernel32.lib |
| DLL | Kernel32.dll |
関連項目
ディレクトリ管理 について
ボリューム管理 の
CloseHandle の
CreateDirectory の
CreateDirectoryEx の
CreateFileTransacted の
CreateMailSlot の
CreateNamedPipe の
ファイル の作成、削除、および保守
DeleteFile の
DeviceIoControl の
関数
GetLastError の
の概要に関するトピック
ReadFile の
ReadFileEx の
SetFileAttributes の
WriteFile の
WriteFileEx の