Win32 API 日本語リファレンス
ホームStorage.FileSystem › CreateFileA

CreateFileA

関数
ファイルやデバイスを作成または開いてハンドルを返す(ANSI版)。
DLLKERNEL32.dll文字セットANSI (-A)呼出規約winapiSetLastErrorあり対応OSWindows XP 以降

シグネチャ

// KERNEL32.dll  (ANSI / -A)
#include <windows.h>

HANDLE CreateFileA(
    LPCSTR lpFileName,
    DWORD dwDesiredAccess,
    FILE_SHARE_MODE dwShareMode,
    SECURITY_ATTRIBUTES* lpSecurityAttributes,   // optional
    FILE_CREATION_DISPOSITION dwCreationDisposition,
    FILE_FLAGS_AND_ATTRIBUTES dwFlagsAndAttributes,
    HANDLE hTemplateFile   // optional
);

パラメーター

名前方向説明
lpFileNameLPCSTRin

作成または開くファイルまたはデバイスの名前。この名前にはスラッシュ (/) またはバックスラッシュ (\) のいずれかを使用できます。

既定では、名前は MAX_PATH 文字に制限されます。この制限を 32,767 ワイド文字に拡張するには、パスの先頭に "\\?\" を付加します。詳細については、ファイル、パス、および名前空間の名前付け を参照してください。

ヒント

Windows 10 バージョン 1607 以降では、"\\?\" を付加せずに MAX_PATH の制限を解除するようオプトインできます。詳細については、ファイル、パス、および名前空間の名前付け の「最大パス長の制限」セクションを参照してください。

特別なデバイス名については、 Defining an MS-DOS Device Name を参照してください。

ファイルストリームを作成するには、ファイル名、コロン、続いてストリーム名を指定します。詳細については、 File Streams を参照してください。

dwDesiredAccessDWORDin

ファイルまたはデバイスへの要求されたアクセス。読み取り、書き込み、その両方、またはいずれでもないことを示す 0 のいずれかにまとめられます。

最もよく使われる値は GENERIC_READGENERIC_WRITE、またはその両方 (GENERIC_READ | GENERIC_WRITE) です。詳細については、 Generic Access RightsFile Security and Access RightsFile Access Rights Constants、および ACCESS_MASK を参照してください。

このパラメーターが 0 の場合、アプリケーションは、GENERIC_READ アクセスが拒否される状況であっても、そのファイルまたはデバイスにアクセスせずに、ファイル、ディレクトリ、デバイスの属性などの特定のメタデータを照会できます。

既に開いているハンドルを持つオープン要求において dwShareMode パラメーターで指定されている共有モードと競合するアクセスモードを要求することはできません。

詳細については、本トピックの「解説」セクションおよび Creating and Opening Files を参照してください。

dwShareModeFILE_SHARE_MODEin

ファイルまたはデバイスに要求する共有モード。読み取り、書き込み、その両方、削除、これらすべて、またはいずれでもないのいずれかです (次の表を参照)。属性または拡張属性へのアクセス要求は、このフラグの影響を受けません。

このパラメーターが 0 で、かつ CreateFile が成功した場合、そのファイルまたはデバイスは共有できず、ハンドルが閉じられるまで再び開くことはできません。詳細については、「解説」セクションを参照してください。

既に開いているハンドルを持つ既存の要求で指定されているアクセスモードと競合する共有モードを要求することはできません。その場合、CreateFile は失敗し、 GetLastError 関数は ERROR_SHARING_VIOLATION を返します。

別のプロセスがファイルまたはデバイスを開いている間にプロセスがそれを共有できるようにするには、次の値の互換性のある組み合わせを 1 つ以上使用します。このパラメーターと dwDesiredAccess パラメーターの有効な組み合わせの詳細については、 Creating and Opening Files を参照してください。

各オープンハンドルの共有オプションは、プロセスのコンテキストに関係なく、そのハンドルが閉じられるまで有効です。
意味
0
0x00000000
他のプロセスが削除、読み取り、または書き込みアクセスを要求した場合に、ファイルまたはデバイスを開くことを禁止します。
FILE_SHARE_DELETE
0x00000004
ファイルまたはデバイスに対する後続のオープン操作が削除アクセスを要求できるようにします。

このフラグを指定しない場合、他のプロセスは削除アクセスを要求するとファイルまたはデバイスを開けません。

このフラグが指定されておらず、かつファイルまたはデバイスが既に削除アクセスで開かれている場合、関数は失敗します。

削除アクセスは、削除操作と名前変更操作の両方を許可します。
FILE_SHARE_READ
0x00000001
ファイルまたはデバイスに対する後続のオープン操作が読み取りアクセスを要求できるようにします。

このフラグを指定しない場合、他のプロセスは読み取りアクセスを要求するとファイルまたはデバイスを開けません。

このフラグが指定されておらず、かつファイルまたはデバイスが既に読み取りアクセスで開かれている場合、関数は失敗します。

FILE_SHARE_WRITE
0x00000002
ファイルまたはデバイスに対する後続のオープン操作が書き込みアクセスを要求できるようにします。

このフラグを指定しない場合、他のプロセスは書き込みアクセスを要求するとファイルまたはデバイスを開けません。

このフラグが指定されておらず、かつファイルまたはデバイスが既に書き込みアクセスで開かれているか、書き込みアクセス付きのファイルマッピングを持つ場合、関数は失敗します。

lpSecurityAttributesSECURITY_ATTRIBUTES*inoptional

SECURITY_ATTRIBUTES 構造体へのポインター。この構造体には、別個でありながら関連する 2 つのデータメンバー、すなわち省略可能なセキュリティ記述子と、返されたハンドルを子プロセスが継承できるかどうかを決定するブール値が含まれます。

このパラメーターには NULL を指定できます。

このパラメーターが NULL の場合、CreateFile が返すハンドルは、アプリケーションが作成する子プロセスによって継承できず、返されたハンドルに関連付けられたファイルまたはデバイスには既定のセキュリティ記述子が割り当てられます。

構造体の lpSecurityDescriptor メンバーは、ファイルまたはデバイスの SECURITY_DESCRIPTOR を指定します。このメンバーが NULL の場合、返されたハンドルに関連付けられたファイルまたはデバイスには既定のセキュリティ記述子が割り当てられます。

CreateFile は、既存のファイルまたはデバイスを開く際には lpSecurityDescriptor メンバーを無視しますが、bInheritHandle メンバーは引き続き使用します。

構造体の bInheritHandle メンバーは、返されたハンドルが継承可能かどうかを指定します。

詳細については、「解説」セクションを参照してください。

dwCreationDispositionFILE_CREATION_DISPOSITIONin

存在する、または存在しないファイルまたはデバイスに対して行うアクション。

ファイル以外のデバイスの場合、このパラメーターは通常 OPEN_EXISTING に設定します。

詳細については、「解説」セクションを参照してください。

このパラメーターには、次のいずれかの値を指定する必要があります。これらを組み合わせることはできません。

意味
CREATE_ALWAYS
2
常に新しいファイルを作成します。

指定したファイルが存在し、書き込み可能な場合、関数はそのファイルを切り詰めて成功し、last-error コードは ERROR_ALREADY_EXISTS (183) に設定されます。

指定したファイルが存在せず、かつ有効なパスである場合、新しいファイルが作成され、関数は成功し、last-error コードは 0 に設定されます。

詳細については、本トピックの「解説」セクションを参照してください。

CREATE_NEW
1
ファイルがまだ存在しない場合にのみ、新しいファイルを作成します。

指定したファイルが存在する場合、関数は失敗し、last-error コードは ERROR_FILE_EXISTS (80) に設定されます。

指定したファイルが存在せず、かつ書き込み可能な場所への有効なパスである場合、新しいファイルが作成されます。

OPEN_ALWAYS
4
常にファイルを開きます。

指定したファイルが存在する場合、関数は成功し、last-error コードは ERROR_ALREADY_EXISTS (183) に設定されます。

指定したファイルが存在せず、かつ書き込み可能な場所への有効なパスである場合、関数はファイルを作成し、last-error コードは 0 に設定されます。

OPEN_EXISTING
3
ファイルまたはデバイスが存在する場合にのみ、それを開きます。

指定したファイルまたはデバイスが存在しない場合、関数は失敗し、last-error コードは ERROR_FILE_NOT_FOUND (2) に設定されます。

デバイスの詳細については、「解説」セクションを参照してください。

TRUNCATE_EXISTING
5
ファイルが存在する場合にのみ、それを開いてサイズが 0 バイトになるように切り詰めます。

指定したファイルが存在しない場合、関数は失敗し、last-error コードは ERROR_FILE_NOT_FOUND (2) に設定されます。

呼び出し元プロセスは、dwDesiredAccess パラメーターの一部として GENERIC_WRITE ビットを設定してファイルを開く必要があります。

dwFlagsAndAttributesFILE_FLAGS_AND_ATTRIBUTESin

ファイルまたはデバイスの属性とフラグ。ファイルの場合、最も一般的な既定値は FILE_ATTRIBUTE_NORMAL です。

このパラメーターには、使用可能なファイル属性 (FILE_ATTRIBUTE_*) の任意の組み合わせを含めることができます。その他のすべてのファイル属性は FILE_ATTRIBUTE_NORMAL を上書きします。

このパラメーターには、ファイルまたはデバイスのキャッシュ動作、アクセスモード、その他の特殊用途のフラグを制御するためのフラグ (FILE_FLAG_*) の組み合わせを含めることもできます。これらは任意の FILE_ATTRIBUTE_* 値と組み合わせられます。

このパラメーターには、SECURITY_SQOS_PRESENT フラグを指定することで、Security Quality of Service (SQOS) 情報を含めることもできます。SQOS 関連のフラグに関する追加情報は、属性とフラグの表に続く表に示されています。

CreateFile が既存のファイルを開くとき、通常はファイルフラグを既存のファイルのファイル属性と組み合わせ、dwFlagsAndAttributes の一部として指定されたファイル属性は無視されます。特殊なケースについては、 Creating and Opening Files で詳しく説明しています。
以下のファイル属性とフラグの一部は、ファイルにのみ適用され、CreateFile が開けるその他すべての種類のデバイスに必ずしも適用されるわけではありません。追加情報については、本トピックの「解説」セクションおよび Creating and Opening Files を参照してください。

ファイル属性へのより高度なアクセスについては、 SetFileAttributes を参照してください。すべてのファイル属性とその値および説明の完全な一覧については、 File Attribute Constants を参照してください。

属性 意味
FILE_ATTRIBUTE_ARCHIVE
32 (0x20)
ファイルをアーカイブする必要があります。アプリケーションはこの属性を使用して、バックアップまたは削除の対象としてファイルにマークを付けます。
FILE_ATTRIBUTE_ENCRYPTED
16384 (0x4000)
ファイルまたはディレクトリが暗号化されています。ファイルの場合、これはファイル内のすべてのデータが暗号化されていることを意味します。ディレクトリの場合、これは新しく作成されるファイルおよびサブディレクトリで暗号化が既定となることを意味します。詳細については、File Encryption を参照してください。

このフラグは、FILE_ATTRIBUTE_SYSTEM も指定されている場合は効果がありません。

このフラグは、Windows の Home、Home Premium、Starter、または ARM エディションではサポートされていません。

FILE_ATTRIBUTE_HIDDEN
2 (0x2)
ファイルは隠しファイルです。通常のディレクトリ一覧には含めません。
FILE_ATTRIBUTE_NORMAL
128 (0x80)
ファイルにその他の属性が設定されていません。この属性は単独で使用する場合にのみ有効です。
FILE_ATTRIBUTE_OFFLINE
4096 (0x1000)
ファイルのデータがすぐには利用できません。この属性は、ファイルデータが物理的にオフラインストレージに移動されたことを示します。この属性は、階層型ストレージ管理ソフトウェアであるリモートストレージによって使用されます。アプリケーションがこの属性をむやみに変更しないでください。
FILE_ATTRIBUTE_READONLY
1 (0x1)
ファイルは読み取り専用です。アプリケーションはファイルを読み取ることはできますが、書き込みや削除はできません。
FILE_ATTRIBUTE_SYSTEM
4 (0x4)
ファイルはオペレーティングシステムの一部であるか、オペレーティングシステムによって排他的に使用されます。
FILE_ATTRIBUTE_TEMPORARY
256 (0x100)
ファイルは一時的なストレージとして使用されています。

詳細については、本トピックの Caching Behavior セクションを参照してください。

フラグ 意味
FILE_FLAG_BACKUP_SEMANTICS
0x02000000
ファイルはバックアップまたは復元操作のために開かれるか作成されます。呼び出し元プロセスが SE_BACKUP_NAME および SE_RESTORE_NAME 特権を持っている場合、システムはそのプロセスがファイルセキュリティチェックを上書きすることを保証します。詳細については、 Changing Privileges in a Token を参照してください。

ディレクトリへのハンドルを取得するには、このフラグを設定する必要があります。ディレクトリハンドルは、一部の関数にファイルハンドルの代わりに渡すことができます。詳細については、「解説」セクションを参照してください。

FILE_FLAG_DELETE_ON_CLOSE
0x04000000
指定したハンドルおよびその他の開いている、または複製されたハンドルを含む、すべてのハンドルが閉じられた直後にファイルが削除されます。

ファイルへの既存の開いているハンドルがある場合、それらがすべて FILE_SHARE_DELETE 共有モードで開かれていない限り、呼び出しは失敗します。

そのファイルに対する後続のオープン要求は、FILE_SHARE_DELETE 共有モードが指定されていない限り失敗します。

FILE_FLAG_NO_BUFFERING
0x20000000
ファイルまたはデバイスが、データの読み取りおよび書き込みに対するシステムキャッシュなしで開かれます。このフラグはハードディスクのキャッシュやメモリマップトファイルには影響しません。

FILE_FLAG_NO_BUFFERING フラグを使用して CreateFile で開いたファイルを正しく扱うには厳密な要件があります。詳細については、 File Buffering を参照してください。

FILE_FLAG_OPEN_NO_RECALL
0x00100000
ファイルデータは要求されますが、引き続きリモートストレージに配置されたままにする必要があります。ローカルストレージに転送し直すべきではありません。このフラグはリモートストレージシステムで使用するためのものです。
FILE_FLAG_OPEN_REPARSE_POINT
0x00200000
通常の リパースポイント 処理は行われません。CreateFile はリパースポイントを開こうとします。ファイルが開かれると、リパースポイントを制御するフィルターが動作しているかどうかにかかわらず、ファイルハンドルが返されます。

このフラグは CREATE_ALWAYS フラグと併用できません。

ファイルがリパースポイントでない場合、このフラグは無視されます。

詳細については、「解説」セクションを参照してください。

FILE_FLAG_OVERLAPPED
0x40000000
ファイルまたはデバイスが非同期 I/O のために開かれるか作成されます。

このハンドルを使用した後続の I/O 操作が完了すると、OVERLAPPED 構造体で指定されたイベントがシグナル状態に設定されます。

このフラグを指定すると、ファイルを同時の読み取り操作と書き込み操作に使用できます。

このフラグを指定しない場合、読み取り関数および書き込み関数の呼び出しで OVERLAPPED 構造体を指定しても、I/O 操作は直列化されます。

このフラグで作成したファイルハンドルを使用する際の考慮事項については、本トピックの Synchronous and Asynchronous I/O Handles セクションを参照してください。

FILE_FLAG_POSIX_SEMANTICS
0x01000000
アクセスは POSIX のルールに従って行われます。これには、その命名をサポートするファイルシステムにおいて、大文字と小文字のみが異なる名前を持つ複数のファイルを許可することが含まれます。このオプションを使用する際は注意してください。このフラグで作成されたファイルは、MS-DOS または 16 ビット Windows 向けに作成されたアプリケーションからアクセスできない場合があるためです。
FILE_FLAG_RANDOM_ACCESS
0x10000000
アクセスはランダムであることが意図されています。システムはこれをファイルキャッシュを最適化するためのヒントとして使用できます。

このフラグは、ファイルシステムがキャッシュ I/O と FILE_FLAG_NO_BUFFERING をサポートしていない場合は効果がありません。

詳細については、本トピックの Caching Behavior セクションを参照してください。

FILE_FLAG_SESSION_AWARE
0x00800000
ファイルまたはデバイスがセッション認識付きで開かれます。このフラグを指定しない場合、セッションごとのデバイス (RemoteFX USB リダイレクトを使用するデバイスなど) は、セッション 0 で実行されているプロセスからは開けません。このフラグは、セッション 0 にない呼び出し元には効果がありません。このフラグは Windows のサーバーエディションでのみサポートされています。

Windows Server 2008 R2 および Windows Server 2008: このフラグは Windows Server 2012 より前ではサポートされていません。

FILE_FLAG_SEQUENTIAL_SCAN
0x08000000
アクセスは先頭から末尾への順次アクセスであることが意図されています。システムはこれをファイルキャッシュを最適化するためのヒントとして使用できます。

リードビハインド (つまり逆方向スキャン) を使用する場合は、このフラグを使用しないでください。

このフラグは、ファイルシステムがキャッシュ I/O と FILE_FLAG_NO_BUFFERING をサポートしていない場合は効果がありません。

詳細については、本トピックの Caching Behavior セクションを参照してください。

FILE_FLAG_WRITE_THROUGH
0x80000000
書き込み操作は中間キャッシュを経由せず、直接ディスクに書き込まれます。

追加情報については、本トピックの Caching Behavior セクションを参照してください。

dwFlagsAndAttributes パラメーターには、SQOS 情報を指定することもできます。詳細については、 Impersonation Levels を参照してください。呼び出し元アプリケーションが dwFlagsAndAttributes の一部として SECURITY_SQOS_PRESENT フラグを指定する場合、次の値を 1 つ以上含めることもできます。

セキュリティフラグ 意味
SECURITY_ANONYMOUS
Anonymous 偽装レベルでクライアントを偽装します。
SECURITY_CONTEXT_TRACKING
セキュリティ追跡モードが動的です。このフラグを指定しない場合、セキュリティ追跡モードは静的です。
SECURITY_DELEGATION
Delegation 偽装レベルでクライアントを偽装します。
SECURITY_EFFECTIVE_ONLY
クライアントのセキュリティコンテキストのうち、有効化されている側面のみがサーバーで利用できます。このフラグを指定しない場合、クライアントのセキュリティコンテキストのすべての側面が利用できます。

これにより、クライアントは、サーバーがクライアントを偽装している間に使用できるグループと特権を制限できます。

SECURITY_IDENTIFICATION
Identification 偽装レベルでクライアントを偽装します。
SECURITY_IMPERSONATION
Impersonation レベルでクライアントを偽装します。これは、SECURITY_SQOS_PRESENT フラグとともに他のフラグが指定されていない場合の既定の動作です。
hTemplateFileHANDLEinoptional

GENERIC_READ アクセス権を持つテンプレートファイルへの有効なハンドル。テンプレートファイルは、作成中のファイルのファイル属性と拡張属性を提供します。

このパラメーターには NULL を指定できます。

既存のファイルを開く場合、CreateFile はこのパラメーターを無視します。

新しい暗号化されたファイルを開く場合、そのファイルは親ディレクトリから随意アクセス制御リストを継承します。追加情報については、 File Encryption を参照してください。

戻り値の型: HANDLE

公式ドキュメント

ファイルまたは I/O デバイスを作成または開きます。よく使われる I/O デバイスには次のものがあります: ファイル、ファイルストリーム、ディレクトリ、物理ディスク、ボリューム、コンソールバッファー、テープドライブ、通信リソース、メールスロット、パイプ。(ANSI)

戻り値

関数が成功した場合、戻り値は指定したファイル、デバイス、名前付きパイプ、またはメールスロットへの開いているハンドルです。

関数が失敗した場合、戻り値は INVALID_HANDLE_VALUE です。拡張エラー情報を取得するには、GetLastError を呼び出します。

解説(Remarks)

CreateFile は当初、特にファイルとの対話のために開発されましたが、その後拡張および強化され、Windows 開発者が利用できるその他のほとんどの種類の I/O デバイスやメカニズムを含むようになりました。このセクションでは、開発者がさまざまなコンテキストおよびさまざまな I/O 種別で CreateFile を使用する際に経験する可能性のあるさまざまな問題を取り上げます。本文中では、ファイルシステム上の実際のファイルに格納されたデータを具体的に指す場合にのみ ファイル という語を使用するよう努めています。ただし、ファイル の一部の用法は、ファイルのようなメカニズムをサポートする I/O オブジェクトをより一般的に指す場合があります。ファイル という用語のこのような大まかな使用は、前述の歴史的な理由から、定数名やパラメーター名で特によく見られます。

アプリケーションが CreateFile によって返されたオブジェクトハンドルの使用を終えたら、CloseHandle 関数を使用してハンドルを閉じます。これはシステムリソースを解放するだけでなく、ファイルやデバイスの共有、データのディスクへのコミットといった事柄にも広範な影響を及ぼす可能性があります。具体的な内容は、本トピック内で適宜記載しています。

Windows Server 2003 および Windows XP: dwDesiredAccess パラメーターの値が DELETE アクセスフラグ (0x00010000) と他の任意のアクセスフラグとの OR 結合であり、かつリモートのファイルまたはディレクトリが FILE_SHARE_DELETE で開かれていない場合に、リモートコンピューター上のファイルまたはディレクトリを削除目的で開こうとすると、共有違反が発生します。このシナリオで共有違反を回避するには、リモートのファイルまたはディレクトリを DELETE アクセス権のみで開くか、ファイルまたはディレクトリを削除目的で開かずに DeleteFile を呼び出します。

NTFS ファイルシステムなど一部のファイルシステムは、個々のファイルおよびディレクトリの圧縮または暗号化をサポートしています。このサポートを備えたファイルシステムがマウントされているボリュームでは、新しいファイルはそのディレクトリの圧縮属性と暗号化属性を継承します。

CreateFile を使用して、ファイルまたはディレクトリの圧縮、展開、または復号を制御することはできません。詳細については、 Creating and Opening FilesFile Compression and Decompression、および File Encryption を参照してください。

Windows Server 2003 および Windows XP: 下位互換性のため、lpSecurityAttributes でセキュリティ記述子を指定しても、CreateFile は継承ルールを適用しません。継承をサポートするため、後でこのファイルのセキュリティ記述子を照会する関数は、ヒューリスティックに継承が有効であると判断して報告する場合があります。詳細については、 Automatic Propagation of Inheritable ACEs を参照してください。

前述のとおり、lpSecurityAttributes パラメーターが NULL の場合、CreateFile が返すハンドルは、アプリケーションが作成する子プロセスによって継承できません。このパラメーターに関して、次の情報も該当します。

Windows 8 および Windows Server 2012 では、この関数は次のテクノロジでサポートされています。
テクノロジ サポート
Server Message Block (SMB) 3.0 プロトコル はい
SMB 3.0 Transparent Failover (TFO) 解説を参照
SMB 3.0 with Scale-out File Shares (SO) 解説を参照
Cluster Shared Volume File System (CsvFS) はい
Resilient File System (ReFS) はい

supersede ディスポジションを指定した CreateFile は、既に開いている代替データストリームが存在するファイルに対して実行すると失敗することに注意してください。

シンボリックリンクの動作

この関数の呼び出しがファイルを作成する場合、動作に変化はありません。また、FILE_FLAG_OPEN_REPARSE_POINT に関する次の情報を考慮してください。

キャッシュ動作

dwFlagsAndAttributes パラメーターに指定可能な値のいくつかは、ハンドルに関連付けられたデータがシステムによってどのようにキャッシュされるかを制御または変更するために CreateFile によって使用されます。それらは次のとおりです。 これらのフラグがいずれも指定されていない場合、システムは既定の汎用キャッシュ方式を使用します。それ以外の場合、システムキャッシュは各フラグに指定されたとおりに動作します。

これらのフラグの一部は組み合わせるべきではありません。たとえば、FILE_FLAG_RANDOM_ACCESSFILE_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_THROUGHFILE_FLAG_NO_BUFFERING の両方が指定されている場合、システムキャッシュが有効にならないため、データは Windows システムキャッシュを経由せずに即座にディスクにフラッシュされます。オペレーティングシステムは、ハードディスクのローカルなハードウェアキャッシュの永続メディアへのライトスルーも要求します。

すべてのハードディスクハードウェアがこのライトスルー機能をサポートしているわけではありません。
FILE_FLAG_NO_BUFFERING フラグを適切に使用するには、特別なアプリケーション上の考慮が必要です。詳細については、 File Buffering を参照してください。

FILE_FLAG_WRITE_THROUGH によるライトスルー要求は、要求の処理の結果生じるタイムスタンプの更新や名前変更操作などのメタデータの変更も、NTFS にフラッシュさせます。このため、FILE_FLAG_WRITE_THROUGH フラグは、書き込みごとに FlushFileBuffers 関数を呼び出す代わりとして FILE_FLAG_NO_BUFFERING フラグと併用されることがよくあります。後者は不要なパフォーマンス上のペナルティを引き起こす可能性があります。これらのフラグを併用するとそのようなペナルティを回避できます。ファイルとメタデータのキャッシュに関する一般情報については、 File Caching を参照してください。

FILE_FLAG_NO_BUFFERINGFILE_FLAG_OVERLAPPED と組み合わされている場合、I/O がメモリマネージャーの同期操作に依存しないため、これらのフラグは最大限の非同期パフォーマンスをもたらします。ただし、データがキャッシュに保持されないため、一部の I/O 操作はより多くの時間がかかります。また、ファイルメタデータは依然としてキャッシュされる場合があります (たとえば空のファイルを作成するとき)。メタデータが確実にディスクにフラッシュされるようにするには、FlushFileBuffers 関数を使用します。

FILE_ATTRIBUTE_TEMPORARY 属性を指定すると、十分なキャッシュメモリが利用可能な場合、ファイルシステムはデータをマスストレージに書き戻すのを回避します。これは、アプリケーションがハンドルを閉じた後に一時ファイルを削除するためです。その場合、システムはデータの書き込みを完全に回避できます。FILE_ATTRIBUTE_TEMPORARY 属性は、前述のフラグと同じようにデータキャッシュを直接制御するわけではありませんが、書き込みを行わずにできるだけ多くをシステムキャッシュに保持するようシステムに指示します。したがって、特定のアプリケーションでは注意が必要となる場合があります。

ファイル

ファイルの名前を変更または削除し、その直後に復元する場合、システムは復元するファイル情報をキャッシュから検索します。キャッシュされる情報には、その短い名前と長い名前のペアや作成時刻が含まれます。

以前の DeleteFile の呼び出しの結果として削除待ち状態にあるファイルに対して CreateFile を呼び出すと、関数は失敗します。オペレーティングシステムは、ファイルへのすべてのハンドルが閉じられるまでファイルの削除を遅延させます。GetLastErrorERROR_ACCESS_DENIED を返します。

dwDesiredAccess パラメーターには 0 を指定でき、アプリケーションが十分なセキュリティ設定で実行されている場合、ファイルにアクセスせずにファイル属性を照会できます。これは、ファイルを読み取りまたは書き込みアクセスで開かずにその存在をテストしたり、ファイルやディレクトリに関するその他の統計情報を取得したりするのに役立ちます。 Obtaining and Setting File Information および GetFileInformationByHandle を参照してください。

CREATE_ALWAYSFILE_ATTRIBUTE_NORMAL が指定されている場合、ファイルが存在し、かつ FILE_ATTRIBUTE_HIDDEN または FILE_ATTRIBUTE_SYSTEM 属性を持っていると、CreateFile は失敗し、last-error を ERROR_ACCESS_DENIED に設定します。このエラーを回避するには、既存のファイルと同じ属性を指定します。

アプリケーションがネットワーク越しにファイルを作成する場合、dwDesiredAccessGENERIC_WRITE 単独を使用するよりも、GENERIC_READ | GENERIC_WRITE を使用する方が適しています。結果として得られるコードは高速になります。リダイレクターがキャッシュマネージャーを使用でき、より多くのデータを含むより少ない数の SMB を送信できるためです。この組み合わせは、ネットワーク越しにファイルへ書き込む際に時折 ERROR_ACCESS_DENIED が返される問題も回避します。

詳細については、 Creating and Opening Files を参照してください。

同期 I/O ハンドルと非同期 I/O ハンドル

CreateFile は、同期または非同期のいずれかのファイルまたはデバイスのハンドルを作成する機能を提供します。同期ハンドルは、そのハンドルを使用する I/O 関数の呼び出しが完了するまでブロックされるように動作します。一方、非同期ファイルハンドルでは、I/O 操作が完了したかどうかにかかわらず、システムが I/O 関数の呼び出しから即座に戻ることができます。前述のとおり、この同期と非同期の動作は、dwFlagsAndAttributes パラメーター内で FILE_FLAG_OVERLAPPED を指定することによって決定されます。非同期 I/O を使用する際には、いくつかの複雑さと潜在的な落とし穴があります。詳細については、 Synchronous and Asynchronous I/O を参照してください。

ファイルストリーム

NTFS ファイルシステムでは、CreateFile を使用してファイル内に別個のストリームを作成できます。詳細については、 File Streams を参照してください。

ディレクトリ

アプリケーションは CreateFile を使用してディレクトリを作成することはできません。したがって、このユースケースでは dwCreationDisposition に有効なのは OPEN_EXISTING 値のみです。ディレクトリを作成するには、アプリケーションは CreateDirectory または CreateDirectoryEx を呼び出す必要があります。

CreateFile を使用してディレクトリを開くには、dwFlagsAndAttributes の一部として FILE_FLAG_BACKUP_SEMANTICS フラグを指定します。このフラグを SE_BACKUP_NAME および SE_RESTORE_NAME 特権なしで使用する場合でも、適切なセキュリティチェックは引き続き適用されます。

FAT または FAT32 ファイルシステムボリュームのデフラグ中に CreateFile を使用してディレクトリを開く場合、MAXIMUM_ALLOWED アクセス権を指定しないでください。これを行うとディレクトリへのアクセスが拒否されます。代わりに GENERIC_READ アクセス権を指定してください。

詳細については、 About Directory Management を参照してください。

物理ディスクとボリューム

ディスクまたはボリュームへの直接アクセスは制限されています。

Windows Server 2003 および Windows XP: ディスクまたはボリュームへの直接アクセスはこのようには制限されていません。

CreateFile 関数を使用して物理ディスクドライブまたはボリュームを開くことができ、これにより DeviceIoControl 関数で使用できる直接アクセスストレージデバイス (DASD) ハンドルが返されます。これにより、たとえばパーティションテーブルのようなディスクメタデータなど、ディスクまたはボリュームに直接アクセスできます。ただし、この種のアクセスは、ディスクドライブまたはボリュームを潜在的なデータ損失にさらします。このメカニズムを使用してディスクへ誤った書き込みを行うと、その内容がオペレーティングシステムからアクセスできなくなる可能性があるためです。データの整合性を確保するため、DeviceIoControl と、他の API がファイルシステムハンドルとは対照的に直接アクセスハンドルでどのように異なる動作をするかについて、必ず精通しておいてください。

そのような呼び出しが成功するには、次の要件を満たす必要があります。

dwDesiredAccess パラメーターには 0 を指定でき、アプリケーションがデバイスにアクセスせずにデバイス属性を照会できます。これは、たとえばドライブにフロッピーディスクを必要とせずに、アプリケーションがフロッピーディスクドライブのサイズとサポートするフォーマットを判別するのに役立ちます。より上位のデータ読み取り/書き込み権限を必要とせずに統計情報を読み取るためにも使用できます。
物理ドライブ x: を開く場合、lpFileName 文字列は次の形式にする必要があります: "\\.\PhysicalDriveX"。ハードディスク番号は 0 から始まります。次の表に、物理ドライブ文字列のいくつかの例を示します。
文字列 意味
"\\.\PhysicalDrive0" 1 番目の物理ドライブを開きます。
"\\.\PhysicalDrive2" 3 番目の物理ドライブを開きます。

ボリュームの物理ドライブ識別子を取得するには、ボリュームへのハンドルを開き、IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS を指定して DeviceIoControl 関数を呼び出します。この制御コードは、ボリュームの 1 つ以上の各エクステントについてディスク番号とオフセットを返します。ボリュームは複数の物理ディスクにまたがることがあります。

物理ドライブを開く例については、 Calling DeviceIoControl を参照してください。

ボリュームまたはリムーバブルメディアドライブ (たとえばフロッピーディスクドライブやフラッシュメモリのサムドライブ) を開く場合、lpFileName 文字列は次の形式にする必要があります: "\\.\X:"。ドライブのルートディレクトリを示す末尾のバックスラッシュ (\) を使用しないでください。次の表に、ドライブ文字列のいくつかの例を示します。

文字列 意味
"\\.\A:" フロッピーディスクドライブ A を開きます。
"\\.\C:" C: ボリュームを開きます。
"\\.\C:\" C: ボリュームのファイルシステムを開きます。

ボリューム名を参照してボリュームを開くこともできます。詳細については、 Naming a Volume を参照してください。

ボリュームには 1 つ以上のマウントされたファイルシステムが含まれます。CreateFile でノンキャッシュオプションが指定されていない場合でも、特定のファイルシステムの裁量により、ボリュームハンドルがノンキャッシュとして開かれることがあります。すべての Microsoft ファイルシステムはボリュームハンドルをノンキャッシュとして開くものと想定すべきです。ファイルに対するノンキャッシュ I/O の制限はボリュームにも適用されます。

データがノンキャッシュであっても、ファイルシステムによってはバッファーアラインメントを必要とする場合もしない場合もあります。ただし、ボリュームを開く際にノンキャッシュオプションが指定されている場合、ボリューム上のファイルシステムにかかわらずバッファーアラインメントが強制されます。すべてのファイルシステムにおいて、ボリュームハンドルをノンキャッシュとして開き、ノンキャッシュ I/O の制限に従うことを推奨します。

ボリュームの末尾の数セクターを読み書きするには、DeviceIoControl を呼び出して FSCTL_ALLOW_EXTENDED_DASD_IO を指定する必要があります。これは、パーティションの読み取りまたは書き込み呼び出しに対して I/O 境界チェックを行わないようファイルシステムドライバーに伝えます。代わりに、境界チェックはデバイスドライバーによって実行されます。

チェンジャーデバイス

DeviceIoControlIOCTL_CHANGER_* 制御コードは、チェンジャーデバイスへのハンドルを受け付けます。チェンジャーデバイスを開くには、次の形式のファイル名を使用します: "\\.\Changerx"。ここで x は、0 から始まる、開くデバイスを示す数値です。C または C++ で記述されたアプリケーションでチェンジャーデバイス 0 を開くには、次のファイル名を使用します: "\\.\Changer0"。

テープドライブ

テープドライブを開くには、次の形式のファイル名を使用します: "\\.\TAPEx"。ここで x は、テープドライブ 0 から始まる、開くドライブを示す数値です。C または C++ で記述されたアプリケーションでテープドライブ 0 を開くには、次のファイル名を使用します: "\\.\TAPE0"。

詳細については、Backup を参照してください。

通信リソース

CreateFile 関数は、シリアルポート COM1 などの通信リソースへのハンドルを作成できます。通信リソースの場合、dwCreationDisposition パラメーターは OPEN_EXISTING でなければならず、dwShareMode パラメーターは 0 (排他アクセス) でなければならず、hTemplateFile パラメーターは NULL でなければなりません。読み取り、書き込み、または読み取り/書き込みアクセスを指定でき、ハンドルはオーバーラップ I/O 用に開くことができます。

9 を超える COM ポート番号を指定するには、次の構文を使用します: "\\.\COM10"。この構文は、すべてのポート番号と、COM ポート番号の指定を許可するハードウェアで機能します。

通信の詳細については、 Communications を参照してください。

コンソール

CreateFile 関数は、コンソール入力 (CONIN$) へのハンドルを作成できます。プロセスが継承または複製の結果としてそれへの開いているハンドルを持っている場合、アクティブな画面バッファー (CONOUT$) へのハンドルも作成できます。呼び出し元プロセスは、継承したコンソールまたは AllocConsole 関数によって割り当てられたコンソールにアタッチされている必要があります。コンソールハンドルの場合、CreateFile のパラメーターを次のように設定します。
パラメーター
lpFileName コンソール入力を指定するには CONIN$ 値を使用します。

コンソール出力を指定するには CONOUT$ 値を使用します。

CONIN$ は、SetStdHandle 関数が標準入力ハンドルをリダイレクトしている場合でも、コンソール入力バッファーへのハンドルを取得します。標準入力ハンドルを取得するには、GetStdHandle 関数を使用します。

CONOUT$ は、SetStdHandle が標準出力ハンドルをリダイレクトしている場合でも、アクティブな画面バッファーへのハンドルを取得します。標準出力ハンドルを取得するには、GetStdHandle を使用します。

dwDesiredAccess GENERIC_READ | GENERIC_WRITE が推奨されますが、いずれか一方でアクセスを制限することもできます。
dwShareMode CONIN$ を開くときは FILE_SHARE_READ を指定します。CONOUT$ を開くときは FILE_SHARE_WRITE を指定します。

呼び出し元プロセスがコンソールを継承する場合、または子プロセスがコンソールにアクセスできるようにする場合、このパラメーターは FILE_SHARE_READ | FILE_SHARE_WRITE でなければなりません。

lpSecurityAttributes コンソールを継承させたい場合、SECURITY_ATTRIBUTES 構造体の bInheritHandle メンバーは TRUE でなければなりません。
dwCreationDisposition CreateFile を使用してコンソールを開くときは、OPEN_EXISTING を指定する必要があります。
dwFlagsAndAttributes 無視されます。
hTemplateFile 無視されます。

次の表に、dwDesiredAccesslpFileName のさまざまな設定を示します。

lpFileName dwDesiredAccess 結果
"CON" GENERIC_READ コンソールを入力用に開きます。
"CON" GENERIC_WRITE コンソールを出力用に開きます。
"CON" GENERIC_READ | GENERIC_WRITE CreateFile が失敗します。GetLastErrorERROR_FILE_NOT_FOUND を返します。

メールスロット

CreateFile がメールスロットのクライアント側を開く場合、メールスロットサーバーが CreateMailSlot 関数でローカルメールスロットを作成する前にメールスロットクライアントがそれを開こうとすると、関数は INVALID_HANDLE_VALUE を返します。

詳細については、Mailslots を参照してください。

パイプ

CreateFile が名前付きパイプのクライアント側を開く場合、関数はリッスン状態にある名前付きパイプの任意のインスタンスを使用します。開いたプロセスは必要なだけハンドルを複製できますが、いったん開かれると、その名前付きパイプインスタンスは別のクライアントから開くことができません。パイプを開くときに指定するアクセスは、CreateNamedPipe 関数の dwOpenMode パラメーターで指定されたアクセスと互換性がなければなりません。

この操作の前にサーバーで CreateNamedPipe 関数が正常に呼び出されていない場合、パイプは存在せず、CreateFileERROR_FILE_NOT_FOUND で失敗します。

アクティブなパイプインスタンスが少なくとも 1 つ存在するが、サーバーに利用可能なリスナーパイプがない場合 (つまりすべてのパイプインスタンスが現在接続されている場合)、CreateFileERROR_PIPE_BUSY で失敗します。

詳細については、Pipes を参照してください。

ファイル操作の例は、次のトピックに示されています。

物理デバイス I/O は、次のトピックで示されています。 名前付きパイプを使用した例は、 Named Pipe Client にあります。

メールスロットを扱う例は、 Writing to a Mailslot に示されています。

テープバックアップのコードスニペットは、 Creating a Backup Application にあります。

メモ

fileapi.h ヘッダーは、UNICODE プリプロセッサ定数の定義に基づいてこの関数の ANSI 版または Unicode 版を自動的に選択するエイリアスとして CreateFile を定義します。エンコーディング中立のエイリアスの使用を、エンコーディング中立でないコードと混在させると、コンパイルエラーまたは実行時エラーを引き起こす不整合が生じる可能性があります。詳細については、Conventions for Function Prototypes を参照してください。

出典・ライセンス: 上記「公式ドキュメント」の内容は Microsoft の Win32 API ドキュメント(MicrosoftDocs/sdk-api)を日本語に翻訳・改変したものです。© Microsoft Corporation. CC BY 4.0 で提供。
Microsoft 公式リファレンス: 英語 (en-us) · 日本語 (ja-jp) · 原文ソース (GitHub)

各言語での呼び出し定義

// KERNEL32.dll  (ANSI / -A)
#include <windows.h>

HANDLE CreateFileA(
    LPCSTR lpFileName,
    DWORD dwDesiredAccess,
    FILE_SHARE_MODE dwShareMode,
    SECURITY_ATTRIBUTES* lpSecurityAttributes,   // optional
    FILE_CREATION_DISPOSITION dwCreationDisposition,
    FILE_FLAGS_AND_ATTRIBUTES dwFlagsAndAttributes,
    HANDLE hTemplateFile   // optional
);
[DllImport("KERNEL32.dll", CharSet = CharSet.Ansi, SetLastError = true, ExactSpelling = true)]
static extern IntPtr CreateFileA(
    [MarshalAs(UnmanagedType.LPStr)] string lpFileName,   // LPCSTR
    uint dwDesiredAccess,   // DWORD
    uint dwShareMode,   // FILE_SHARE_MODE
    IntPtr lpSecurityAttributes,   // SECURITY_ATTRIBUTES* optional
    uint dwCreationDisposition,   // FILE_CREATION_DISPOSITION
    uint dwFlagsAndAttributes,   // FILE_FLAGS_AND_ATTRIBUTES
    IntPtr hTemplateFile   // HANDLE optional
);
<DllImport("KERNEL32.dll", CharSet:=CharSet.Ansi, SetLastError:=True, ExactSpelling:=True)>
Public Shared Function CreateFileA(
    <MarshalAs(UnmanagedType.LPStr)> lpFileName As String,   ' LPCSTR
    dwDesiredAccess As UInteger,   ' DWORD
    dwShareMode As UInteger,   ' FILE_SHARE_MODE
    lpSecurityAttributes As IntPtr,   ' SECURITY_ATTRIBUTES* optional
    dwCreationDisposition As UInteger,   ' FILE_CREATION_DISPOSITION
    dwFlagsAndAttributes As UInteger,   ' FILE_FLAGS_AND_ATTRIBUTES
    hTemplateFile As IntPtr   ' HANDLE optional
) As IntPtr
End Function
' lpFileName : LPCSTR
' dwDesiredAccess : DWORD
' dwShareMode : FILE_SHARE_MODE
' lpSecurityAttributes : SECURITY_ATTRIBUTES* optional
' dwCreationDisposition : FILE_CREATION_DISPOSITION
' dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES
' hTemplateFile : HANDLE optional
Declare PtrSafe Function CreateFileA Lib "kernel32" ( _
    ByVal lpFileName As String, _
    ByVal dwDesiredAccess As Long, _
    ByVal dwShareMode As Long, _
    ByVal lpSecurityAttributes As LongPtr, _
    ByVal dwCreationDisposition As Long, _
    ByVal dwFlagsAndAttributes As Long, _
    ByVal hTemplateFile As LongPtr) As LongPtr
' VBA7前提(PtrSafe)。32bit Office では LongPtr→Long。Integer=16bit / Long=32bit / LongLong=64bit。
import ctypes
from ctypes import wintypes

CreateFileA = ctypes.windll.kernel32.CreateFileA
CreateFileA.restype = ctypes.c_void_p
CreateFileA.argtypes = [
    wintypes.LPCSTR,  # lpFileName : LPCSTR
    wintypes.DWORD,  # dwDesiredAccess : DWORD
    wintypes.DWORD,  # dwShareMode : FILE_SHARE_MODE
    ctypes.c_void_p,  # lpSecurityAttributes : SECURITY_ATTRIBUTES* optional
    wintypes.DWORD,  # dwCreationDisposition : FILE_CREATION_DISPOSITION
    wintypes.DWORD,  # dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES
    wintypes.HANDLE,  # hTemplateFile : HANDLE optional
]
# GetLastError: use ctypes.GetLastError() (or ctypes.WinDLL(use_last_error=True))
require 'fiddle'
require 'fiddle/import'

lib = Fiddle.dlopen('KERNEL32.dll')
CreateFileA = Fiddle::Function.new(
  lib['CreateFileA'],
  [
    Fiddle::TYPE_VOIDP,  # lpFileName : LPCSTR
    -Fiddle::TYPE_INT,  # dwDesiredAccess : DWORD
    -Fiddle::TYPE_INT,  # dwShareMode : FILE_SHARE_MODE
    Fiddle::TYPE_VOIDP,  # lpSecurityAttributes : SECURITY_ATTRIBUTES* optional
    -Fiddle::TYPE_INT,  # dwCreationDisposition : FILE_CREATION_DISPOSITION
    -Fiddle::TYPE_INT,  # dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES
    Fiddle::TYPE_VOIDP,  # hTemplateFile : HANDLE optional
  ],
  Fiddle::TYPE_VOIDP)
#[link(name = "kernel32")]
extern "system" {
    fn CreateFileA(
        lpFileName: *const u8,  // LPCSTR
        dwDesiredAccess: u32,  // DWORD
        dwShareMode: u32,  // FILE_SHARE_MODE
        lpSecurityAttributes: *mut SECURITY_ATTRIBUTES,  // SECURITY_ATTRIBUTES* optional
        dwCreationDisposition: u32,  // FILE_CREATION_DISPOSITION
        dwFlagsAndAttributes: u32,  // FILE_FLAGS_AND_ATTRIBUTES
        hTemplateFile: *mut core::ffi::c_void  // HANDLE optional
    ) -> *mut core::ffi::c_void;
}
// crates: windows-sys provides ready-made bindings for this API.
$sig = @"
[DllImport("KERNEL32.dll", CharSet = CharSet.Ansi, SetLastError = true)]
public static extern IntPtr CreateFileA([MarshalAs(UnmanagedType.LPStr)] string lpFileName, uint dwDesiredAccess, uint dwShareMode, IntPtr lpSecurityAttributes, uint dwCreationDisposition, uint dwFlagsAndAttributes, IntPtr hTemplateFile);
"@
$api = Add-Type -MemberDefinition $sig -Name 'KERNEL32_CreateFileA' -Namespace Win32 -PassThru
# $api::CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
#uselib "KERNEL32.dll"
#func global CreateFileA "CreateFileA" sptr, sptr, sptr, sptr, sptr, sptr, sptr
; CreateFileA lpFileName, dwDesiredAccess, dwShareMode, varptr(lpSecurityAttributes), dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile   ; 戻り値は stat
; lpFileName : LPCSTR -> "sptr"
; dwDesiredAccess : DWORD -> "sptr"
; dwShareMode : FILE_SHARE_MODE -> "sptr"
; lpSecurityAttributes : SECURITY_ATTRIBUTES* optional -> "sptr"
; dwCreationDisposition : FILE_CREATION_DISPOSITION -> "sptr"
; dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES -> "sptr"
; hTemplateFile : HANDLE optional -> "sptr"
; ※HSP3.7は #func のため戻り値はシステム変数 stat に格納されます。
出力引数:
#uselib "KERNEL32.dll"
#cfunc global CreateFileA "CreateFileA" str, int, int, var, int, int, sptr
; res = CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
; lpFileName : LPCSTR -> "str"
; dwDesiredAccess : DWORD -> "int"
; dwShareMode : FILE_SHARE_MODE -> "int"
; lpSecurityAttributes : SECURITY_ATTRIBUTES* optional -> "var"
; dwCreationDisposition : FILE_CREATION_DISPOSITION -> "int"
; dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES -> "int"
; hTemplateFile : HANDLE optional -> "sptr"
; ※出力/バッファ引数は var 方式(変数を直接渡す)。varptr 方式にも切替可。
出力引数:
; HANDLE CreateFileA(LPCSTR lpFileName, DWORD dwDesiredAccess, FILE_SHARE_MODE dwShareMode, SECURITY_ATTRIBUTES* lpSecurityAttributes, FILE_CREATION_DISPOSITION dwCreationDisposition, FILE_FLAGS_AND_ATTRIBUTES dwFlagsAndAttributes, HANDLE hTemplateFile)
#uselib "KERNEL32.dll"
#cfunc global CreateFileA "CreateFileA" str, int, int, var, int, int, intptr
; res = CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
; lpFileName : LPCSTR -> "str"
; dwDesiredAccess : DWORD -> "int"
; dwShareMode : FILE_SHARE_MODE -> "int"
; lpSecurityAttributes : SECURITY_ATTRIBUTES* optional -> "var"
; dwCreationDisposition : FILE_CREATION_DISPOSITION -> "int"
; dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES -> "int"
; hTemplateFile : HANDLE optional -> "intptr"
; ※出力/バッファ引数は var 方式(変数を直接渡す)。varptr 方式にも切替可。
import (
	"golang.org/x/sys/windows"
	"unsafe"
)

var (
	kernel32 = windows.NewLazySystemDLL("KERNEL32.dll")
	procCreateFileA = kernel32.NewProc("CreateFileA")
)

// lpFileName (LPCSTR), dwDesiredAccess (DWORD), dwShareMode (FILE_SHARE_MODE), lpSecurityAttributes (SECURITY_ATTRIBUTES* optional), dwCreationDisposition (FILE_CREATION_DISPOSITION), dwFlagsAndAttributes (FILE_FLAGS_AND_ATTRIBUTES), hTemplateFile (HANDLE optional)
r1, _, err := procCreateFileA.Call(
	uintptr(unsafe.Pointer(windows.BytePtrFromString(lpFileName))),
	uintptr(dwDesiredAccess),
	uintptr(dwShareMode),
	uintptr(lpSecurityAttributes),
	uintptr(dwCreationDisposition),
	uintptr(dwFlagsAndAttributes),
	uintptr(hTemplateFile),
)
_ = err  // syscall.Errno (valid when the call sets last-error)
_ = r1   // HANDLE
function CreateFileA(
  lpFileName: PAnsiChar;   // LPCSTR
  dwDesiredAccess: DWORD;   // DWORD
  dwShareMode: DWORD;   // FILE_SHARE_MODE
  lpSecurityAttributes: Pointer;   // SECURITY_ATTRIBUTES* optional
  dwCreationDisposition: DWORD;   // FILE_CREATION_DISPOSITION
  dwFlagsAndAttributes: DWORD;   // FILE_FLAGS_AND_ATTRIBUTES
  hTemplateFile: THandle   // HANDLE optional
): THandle; stdcall;
  external 'KERNEL32.dll' name 'CreateFileA';
result := DllCall("KERNEL32\CreateFileA"
    , "AStr", lpFileName   ; LPCSTR
    , "UInt", dwDesiredAccess   ; DWORD
    , "UInt", dwShareMode   ; FILE_SHARE_MODE
    , "Ptr", lpSecurityAttributes   ; SECURITY_ATTRIBUTES* optional
    , "UInt", dwCreationDisposition   ; FILE_CREATION_DISPOSITION
    , "UInt", dwFlagsAndAttributes   ; FILE_FLAGS_AND_ATTRIBUTES
    , "Ptr", hTemplateFile   ; HANDLE optional
    , "Ptr")   ; return: HANDLE
●CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile) = DLL("KERNEL32.dll", "void* CreateFileA(char*, dword, dword, void*, dword, dword, void*)")
# 呼び出し: CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
# lpFileName : LPCSTR -> "char*"
# dwDesiredAccess : DWORD -> "dword"
# dwShareMode : FILE_SHARE_MODE -> "dword"
# lpSecurityAttributes : SECURITY_ATTRIBUTES* optional -> "void*"
# dwCreationDisposition : FILE_CREATION_DISPOSITION -> "dword"
# dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES -> "dword"
# hTemplateFile : HANDLE optional -> "void*"
# なでしこ1は32bit・ANSI(Shift_JIS)。文字列=char*(ANSI)、ポインタ/ハンドル=void*(4byte)。
const std = @import("std");

extern "kernel32" fn CreateFileA(
    lpFileName: [*c]const u8, // LPCSTR
    dwDesiredAccess: u32, // DWORD
    dwShareMode: u32, // FILE_SHARE_MODE
    lpSecurityAttributes: [*c]SECURITY_ATTRIBUTES, // SECURITY_ATTRIBUTES* optional
    dwCreationDisposition: u32, // FILE_CREATION_DISPOSITION
    dwFlagsAndAttributes: u32, // FILE_FLAGS_AND_ATTRIBUTES
    hTemplateFile: ?*anyopaque // HANDLE optional
) callconv(std.os.windows.WINAPI) ?*anyopaque;
proc CreateFileA(
    lpFileName: cstring,  # LPCSTR
    dwDesiredAccess: uint32,  # DWORD
    dwShareMode: uint32,  # FILE_SHARE_MODE
    lpSecurityAttributes: ptr SECURITY_ATTRIBUTES,  # SECURITY_ATTRIBUTES* optional
    dwCreationDisposition: uint32,  # FILE_CREATION_DISPOSITION
    dwFlagsAndAttributes: uint32,  # FILE_FLAGS_AND_ATTRIBUTES
    hTemplateFile: pointer  # HANDLE optional
): pointer {.importc: "CreateFileA", stdcall, dynlib: "KERNEL32.dll".}
pragma(lib, "kernel32");
extern(Windows)
void* CreateFileA(
    const(char)* lpFileName,   // LPCSTR
    uint dwDesiredAccess,   // DWORD
    uint dwShareMode,   // FILE_SHARE_MODE
    SECURITY_ATTRIBUTES* lpSecurityAttributes,   // SECURITY_ATTRIBUTES* optional
    uint dwCreationDisposition,   // FILE_CREATION_DISPOSITION
    uint dwFlagsAndAttributes,   // FILE_FLAGS_AND_ATTRIBUTES
    void* hTemplateFile   // HANDLE optional
);
ccall((:CreateFileA, "KERNEL32.dll"), stdcall, Ptr{Cvoid},
      (Cstring, UInt32, UInt32, Ptr{SECURITY_ATTRIBUTES}, UInt32, UInt32, Ptr{Cvoid}),
      lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
# lpFileName : LPCSTR -> Cstring
# dwDesiredAccess : DWORD -> UInt32
# dwShareMode : FILE_SHARE_MODE -> UInt32
# lpSecurityAttributes : SECURITY_ATTRIBUTES* optional -> Ptr{SECURITY_ATTRIBUTES}
# dwCreationDisposition : FILE_CREATION_DISPOSITION -> UInt32
# dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES -> UInt32
# hTemplateFile : HANDLE optional -> Ptr{Cvoid}
# stdcall は 32bit のみ意味を持つ(x64 では無視)。
local ffi = require("ffi")
ffi.cdef[[
void* CreateFileA(
    const char* lpFileName,
    uint32_t dwDesiredAccess,
    uint32_t dwShareMode,
    void* lpSecurityAttributes,
    uint32_t dwCreationDisposition,
    uint32_t dwFlagsAndAttributes,
    void* hTemplateFile);
]]
local kernel32 = ffi.load("kernel32")
-- kernel32.CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
-- lpFileName : LPCSTR
-- dwDesiredAccess : DWORD
-- dwShareMode : FILE_SHARE_MODE
-- lpSecurityAttributes : SECURITY_ATTRIBUTES* optional
-- dwCreationDisposition : FILE_CREATION_DISPOSITION
-- dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES
-- hTemplateFile : HANDLE optional
-- 構造体/GUIDへのポインタは cdef が通るよう void* で表記(実型は各引数コメント参照)。値渡し構造体・enum は対応する typedef を cdef に追加すること。
const koffi = require('koffi');
const lib = koffi.load('KERNEL32.dll');
const CreateFileA = lib.func('__stdcall', 'CreateFileA', 'void *', ['str', 'uint32_t', 'uint32_t', 'void *', 'uint32_t', 'uint32_t', 'void *']);
// CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
// lpFileName : LPCSTR -> 'str'
// dwDesiredAccess : DWORD -> 'uint32_t'
// dwShareMode : FILE_SHARE_MODE -> 'uint32_t'
// lpSecurityAttributes : SECURITY_ATTRIBUTES* optional -> 'void *'
// dwCreationDisposition : FILE_CREATION_DISPOSITION -> 'uint32_t'
// dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES -> 'uint32_t'
// hTemplateFile : HANDLE optional -> 'void *'
// 出力ポインタは koffi.out(...) で包む。構造体は koffi.struct で定義。
const lib = Deno.dlopen("KERNEL32.dll", {
  CreateFileA: { parameters: ["buffer", "u32", "u32", "pointer", "u32", "u32", "pointer"], result: "pointer" },
});
// lib.symbols.CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
// lpFileName : LPCSTR -> "buffer"
// dwDesiredAccess : DWORD -> "u32"
// dwShareMode : FILE_SHARE_MODE -> "u32"
// lpSecurityAttributes : SECURITY_ATTRIBUTES* optional -> "pointer"
// dwCreationDisposition : FILE_CREATION_DISPOSITION -> "u32"
// dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES -> "u32"
// hTemplateFile : HANDLE optional -> "pointer"
// 文字列は "buffer"。ANSI(-A) は new TextEncoder() で UTF-8/ANSI バイト列(末尾に \x00)を渡す。
// 値渡し構造体は { struct: [ ...field types... ] } を使用。
<?php
$ffi = FFI::cdef(<<<C
void* CreateFileA(
    const char* lpFileName,
    uint32_t dwDesiredAccess,
    uint32_t dwShareMode,
    void* lpSecurityAttributes,
    uint32_t dwCreationDisposition,
    uint32_t dwFlagsAndAttributes,
    void* hTemplateFile);
C, "KERNEL32.dll");
// $ffi->CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile);
// lpFileName : LPCSTR
// dwDesiredAccess : DWORD
// dwShareMode : FILE_SHARE_MODE
// lpSecurityAttributes : SECURITY_ATTRIBUTES* optional
// dwCreationDisposition : FILE_CREATION_DISPOSITION
// dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES
// hTemplateFile : HANDLE optional
// 構造体/GUIDへのポインタは cdef が通るよう void* で表記(実型は各引数コメント参照)。値渡し構造体・enum は対応する typedef を cdef に追加すること。
// WINAPI(stdcall): x64 では呼出規約が統一されるため問題なし。x86 では __stdcall 対応のラッパが必要な場合あり。
import com.sun.jna.*;
import com.sun.jna.ptr.*;
import com.sun.jna.win32.StdCallLibrary;
import com.sun.jna.win32.W32APIOptions;

public interface Kernel32 extends StdCallLibrary {
    Kernel32 INSTANCE = Native.load("kernel32", Kernel32.class, W32APIOptions.ASCII_OPTIONS);
    Pointer CreateFileA(
        String lpFileName,   // LPCSTR
        int dwDesiredAccess,   // DWORD
        int dwShareMode,   // FILE_SHARE_MODE
        Pointer lpSecurityAttributes,   // SECURITY_ATTRIBUTES* optional
        int dwCreationDisposition,   // FILE_CREATION_DISPOSITION
        int dwFlagsAndAttributes,   // FILE_FLAGS_AND_ATTRIBUTES
        Pointer hTemplateFile   // HANDLE optional
    );
}
@[Link("kernel32")]
lib LibKERNEL32
  fun CreateFileA = CreateFileA(
    lpFileName : UInt8*,   # LPCSTR
    dwDesiredAccess : UInt32,   # DWORD
    dwShareMode : UInt32,   # FILE_SHARE_MODE
    lpSecurityAttributes : SECURITY_ATTRIBUTES*,   # SECURITY_ATTRIBUTES* optional
    dwCreationDisposition : UInt32,   # FILE_CREATION_DISPOSITION
    dwFlagsAndAttributes : UInt32,   # FILE_FLAGS_AND_ATTRIBUTES
    hTemplateFile : Void*   # HANDLE optional
  ) : Void*
end
# 構造体/GUID/enum は lib 内に対応する型定義が必要。
# 呼出規約: x64 は規約統一のため OK。x86(32bit)は WINAPI=stdcall だが Crystal の fun に stdcall 付与構文がなく非対応。
import 'dart:ffi';
import 'package:ffi/ffi.dart';

typedef CreateFileANative = Pointer<Void> Function(Pointer<Utf8>, Uint32, Uint32, Pointer<Void>, Uint32, Uint32, Pointer<Void>);
typedef CreateFileADart = Pointer<Void> Function(Pointer<Utf8>, int, int, Pointer<Void>, int, int, Pointer<Void>);
final CreateFileA = DynamicLibrary.open('KERNEL32.dll')
    .lookupFunction<CreateFileANative, CreateFileADart>('CreateFileA');
// lpFileName : LPCSTR -> Pointer<Utf8>
// dwDesiredAccess : DWORD -> Uint32
// dwShareMode : FILE_SHARE_MODE -> Uint32
// lpSecurityAttributes : SECURITY_ATTRIBUTES* optional -> Pointer<Void>
// dwCreationDisposition : FILE_CREATION_DISPOSITION -> Uint32
// dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES -> Uint32
// hTemplateFile : HANDLE optional -> Pointer<Void>
// 文字列は package:ffi の "...".toNativeUtf16()/toNativeUtf8() で変換。
{$mode objfpc}{$H+}
function CreateFileA(
  lpFileName: PAnsiChar;   // LPCSTR
  dwDesiredAccess: DWORD;   // DWORD
  dwShareMode: DWORD;   // FILE_SHARE_MODE
  lpSecurityAttributes: Pointer;   // SECURITY_ATTRIBUTES* optional
  dwCreationDisposition: DWORD;   // FILE_CREATION_DISPOSITION
  dwFlagsAndAttributes: DWORD;   // FILE_FLAGS_AND_ATTRIBUTES
  hTemplateFile: THandle   // HANDLE optional
): THandle; stdcall;
  external 'KERNEL32.dll' name 'CreateFileA';
import Foreign
import Foreign.C.Types
import Foreign.C.String

foreign import stdcall safe "CreateFileA"
  c_CreateFileA :: CString -> Word32 -> Word32 -> Ptr () -> Word32 -> Word32 -> Ptr () -> IO (Ptr ())
-- lpFileName : LPCSTR -> CString
-- dwDesiredAccess : DWORD -> Word32
-- dwShareMode : FILE_SHARE_MODE -> Word32
-- lpSecurityAttributes : SECURITY_ATTRIBUTES* optional -> Ptr ()
-- dwCreationDisposition : FILE_CREATION_DISPOSITION -> Word32
-- dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES -> Word32
-- hTemplateFile : HANDLE optional -> Ptr ()
-- 要 GHC(Windows)。stdcall は x64 では ccall として扱われる。ブロックする API は safe 呼び出し推奨。
open Ctypes
open Foreign

let createfilea =
  foreign "CreateFileA"
    (string @-> uint32_t @-> uint32_t @-> (ptr void) @-> uint32_t @-> uint32_t @-> (ptr void) @-> returning (ptr void))
(* lpFileName : LPCSTR -> string *)
(* dwDesiredAccess : DWORD -> uint32_t *)
(* dwShareMode : FILE_SHARE_MODE -> uint32_t *)
(* lpSecurityAttributes : SECURITY_ATTRIBUTES* optional -> (ptr void) *)
(* dwCreationDisposition : FILE_CREATION_DISPOSITION -> uint32_t *)
(* dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES -> uint32_t *)
(* hTemplateFile : HANDLE optional -> (ptr void) *)
(* foreign は cdecl 前提。x64 Windows では WINAPI と一致。構造体は ctypes structure を定義のこと。 *)
(cffi:define-foreign-library kernel32 (t "KERNEL32.dll"))
(cffi:use-foreign-library kernel32)

(cffi:defcfun ("CreateFileA" create-file-a :convention :stdcall) :pointer
  (lp-file-name :string)   ; LPCSTR
  (dw-desired-access :uint32)   ; DWORD
  (dw-share-mode :uint32)   ; FILE_SHARE_MODE
  (lp-security-attributes :pointer)   ; SECURITY_ATTRIBUTES* optional
  (dw-creation-disposition :uint32)   ; FILE_CREATION_DISPOSITION
  (dw-flags-and-attributes :uint32)   ; FILE_FLAGS_AND_ATTRIBUTES
  (h-template-file :pointer))   ; HANDLE optional
; isize/usize(INT_PTR/SIZE_T)は x64 前提で :int64/:uint64。x86 では :int32/:uint32。
use Win32::API;
my $CreateFileA = Win32::API::More->new('KERNEL32',
    'HANDLE CreateFileA(LPCSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPVOID lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile)');
# my $ret = $CreateFileA->Call($lpFileName, $dwDesiredAccess, $dwShareMode, $lpSecurityAttributes, $dwCreationDisposition, $dwFlagsAndAttributes, $hTemplateFile);
# lpFileName : LPCSTR -> LPCSTR
# dwDesiredAccess : DWORD -> DWORD
# dwShareMode : FILE_SHARE_MODE -> DWORD
# lpSecurityAttributes : SECURITY_ATTRIBUTES* optional -> LPVOID
# dwCreationDisposition : FILE_CREATION_DISPOSITION -> DWORD
# dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES -> DWORD
# hTemplateFile : HANDLE optional -> HANDLE
# 値渡し構造体は pack() した文字列、または Win32::API::Struct を使用。

関連項目

文字セット違い
類似 API
公式の関連項目
使用する型