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

CreateFileW

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

シグネチャ

// KERNEL32.dll  (Unicode / -W)
#include <windows.h>

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

パラメーター

名前方向説明
lpFileNameLPCWSTRin

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

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

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

既定では、名前は MAX_PATH 文字に制限されます。この制限を 32,767 ワイド文字に拡張するには、パスの先頭に "\\?\" を付加します。詳細については、Naming Files, Paths, and Namespaces を参照してください。

ヒント

Windows 10 バージョン 1607 以降では、"\\?\" を付加せずに MAX_PATH の制限を解除するようにオプトインできます。詳細については、Naming Files, Paths, and Namespaces の「Maximum Path Length Limitation」セクションを参照してください。

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 の場合、返されたハンドルに関連付けられたファイルまたはデバイスには既定のセキュリティ記述子が割り当てられます。

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

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

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

dwCreationDispositionFILE_CREATION_DISPOSITIONin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

指定したファイルが存在しない場合、関数は失敗し、最終エラーコードは 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
通常の reparse point 処理は行われません。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 デバイスは次のとおりです: ファイル、ファイルストリーム、ディレクトリ、物理ディスク、ボリューム、コンソールバッファー、テープドライブ、通信リソース、メールスロット、パイプ。(Unicode)

戻り値

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

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

解説(Remarks)

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

アプリケーションが 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_THROUGHFILE_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 は失敗し、最終エラーを ERROR_ACCESS_DENIED に設定します。このエラーを回避するには、既存のファイルと同じ属性を指定します。

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

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

同期および非同期 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" 最初の物理ドライブを開きます。
"\\.\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 境界チェックを行わないようファイルシステムドライバーに通知します。代わりに、境界チェックはデバイスドライバーによって実行されます。

チェンジャーデバイス

DeviceIoControl 向けの IOCTL_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  (Unicode / -W)
#include <windows.h>

HANDLE CreateFileW(
    LPCWSTR 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.Unicode, SetLastError = true, ExactSpelling = true)]
static extern IntPtr CreateFileW(
    [MarshalAs(UnmanagedType.LPWStr)] string lpFileName,   // LPCWSTR
    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.Unicode, SetLastError:=True, ExactSpelling:=True)>
Public Shared Function CreateFileW(
    <MarshalAs(UnmanagedType.LPWStr)> lpFileName As String,   ' LPCWSTR
    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 : LPCWSTR
' 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 CreateFileW Lib "kernel32" ( _
    ByVal lpFileName As LongPtr, _
    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
' Unicode(W): 文字列は ByVal As LongPtr とし StrPtr(unicodeStr) を渡す
' VBA7前提(PtrSafe)。32bit Office では LongPtr→Long。Integer=16bit / Long=32bit / LongLong=64bit。
import ctypes
from ctypes import wintypes

CreateFileW = ctypes.windll.kernel32.CreateFileW
CreateFileW.restype = ctypes.c_void_p
CreateFileW.argtypes = [
    wintypes.LPCWSTR,  # lpFileName : LPCWSTR
    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')
CreateFileW = Fiddle::Function.new(
  lib['CreateFileW'],
  [
    Fiddle::TYPE_VOIDP,  # lpFileName : LPCWSTR
    -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)
# Wide strings: pass str.encode("UTF-16LE") + "\x00\x00"
#[link(name = "kernel32")]
extern "system" {
    fn CreateFileW(
        lpFileName: *const u16,  // LPCWSTR
        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.Unicode, SetLastError = true)]
public static extern IntPtr CreateFileW([MarshalAs(UnmanagedType.LPWStr)] string lpFileName, uint dwDesiredAccess, uint dwShareMode, IntPtr lpSecurityAttributes, uint dwCreationDisposition, uint dwFlagsAndAttributes, IntPtr hTemplateFile);
"@
$api = Add-Type -MemberDefinition $sig -Name 'KERNEL32_CreateFileW' -Namespace Win32 -PassThru
# $api::CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
#uselib "KERNEL32.dll"
#func global CreateFileW "CreateFileW" wptr, wptr, wptr, wptr, wptr, wptr, wptr
; CreateFileW lpFileName, dwDesiredAccess, dwShareMode, varptr(lpSecurityAttributes), dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile   ; 戻り値は stat
; lpFileName : LPCWSTR -> "wptr"
; dwDesiredAccess : DWORD -> "wptr"
; dwShareMode : FILE_SHARE_MODE -> "wptr"
; lpSecurityAttributes : SECURITY_ATTRIBUTES* optional -> "wptr"
; dwCreationDisposition : FILE_CREATION_DISPOSITION -> "wptr"
; dwFlagsAndAttributes : FILE_FLAGS_AND_ATTRIBUTES -> "wptr"
; hTemplateFile : HANDLE optional -> "wptr"
; ※HSP3.7は #func のため戻り値はシステム変数 stat に格納されます。
出力引数:
#uselib "KERNEL32.dll"
#cfunc global CreateFileW "CreateFileW" wstr, int, int, var, int, int, sptr
; res = CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
; lpFileName : LPCWSTR -> "wstr"
; 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 CreateFileW(LPCWSTR 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 CreateFileW "CreateFileW" wstr, int, int, var, int, int, intptr
; res = CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
; lpFileName : LPCWSTR -> "wstr"
; 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")
	procCreateFileW = kernel32.NewProc("CreateFileW")
)

// lpFileName (LPCWSTR), dwDesiredAccess (DWORD), dwShareMode (FILE_SHARE_MODE), lpSecurityAttributes (SECURITY_ATTRIBUTES* optional), dwCreationDisposition (FILE_CREATION_DISPOSITION), dwFlagsAndAttributes (FILE_FLAGS_AND_ATTRIBUTES), hTemplateFile (HANDLE optional)
r1, _, err := procCreateFileW.Call(
	uintptr(unsafe.Pointer(windows.StringToUTF16Ptr(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 CreateFileW(
  lpFileName: PWideChar;   // LPCWSTR
  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 'CreateFileW';
result := DllCall("KERNEL32\CreateFileW"
    , "WStr", lpFileName   ; LPCWSTR
    , "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
●CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile) = DLL("KERNEL32.dll", "void* CreateFileW(char*, dword, dword, void*, dword, dword, void*)")
# 呼び出し: CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
# lpFileName : LPCWSTR -> "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)。
# ※-W(Unicode)関数。なでしこ1はANSIのため -A 版の利用を推奨。
const std = @import("std");

extern "kernel32" fn CreateFileW(
    lpFileName: [*c]const u16, // LPCWSTR
    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;
// Unicode(-W): UTF-16LE のヌル終端バッファ([*c]const u16)を渡す。
proc CreateFileW(
    lpFileName: WideCString,  # LPCWSTR
    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: "CreateFileW", stdcall, dynlib: "KERNEL32.dll".}
# Unicode(-W): WideCString は newWideCString("...") で生成。
pragma(lib, "kernel32");
extern(Windows)
void* CreateFileW(
    const(wchar)* lpFileName,   // LPCWSTR
    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((:CreateFileW, "KERNEL32.dll"), stdcall, Ptr{Cvoid},
      (Cwstring, UInt32, UInt32, Ptr{SECURITY_ATTRIBUTES}, UInt32, UInt32, Ptr{Cvoid}),
      lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
# lpFileName : LPCWSTR -> Cwstring
# 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 では無視)。
# Unicode(-W): Cwstring には transcode(UInt16, "...") 等で UTF-16 を渡す。
local ffi = require("ffi")
ffi.cdef[[
void* CreateFileW(
    const uint16_t* lpFileName,
    uint32_t dwDesiredAccess,
    uint32_t dwShareMode,
    void* lpSecurityAttributes,
    uint32_t dwCreationDisposition,
    uint32_t dwFlagsAndAttributes,
    void* hTemplateFile);
]]
local kernel32 = ffi.load("kernel32")
-- kernel32.CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
-- lpFileName : LPCWSTR
-- 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 に追加すること。
-- Unicode(-W): uint16_t* には UTF-16LE のバッファ(ffi.new("uint16_t[?]", ...))を渡す。
const koffi = require('koffi');
const lib = koffi.load('KERNEL32.dll');
const CreateFileW = lib.func('__stdcall', 'CreateFileW', 'void *', ['str16', 'uint32_t', 'uint32_t', 'void *', 'uint32_t', 'uint32_t', 'void *']);
// CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
// lpFileName : LPCWSTR -> 'str16'
// 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", {
  CreateFileW: { parameters: ["buffer", "u32", "u32", "pointer", "u32", "u32", "pointer"], result: "pointer" },
});
// lib.symbols.CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile)
// lpFileName : LPCWSTR -> "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"。Unicode(-W) は new TextEncoder() ではなく UTF-16LE のバイト列(末尾に \x00\x00)を Uint8Array で渡す。
// 値渡し構造体は { struct: [ ...field types... ] } を使用。
<?php
$ffi = FFI::cdef(<<<C
void* CreateFileW(
    const uint16_t* lpFileName,
    uint32_t dwDesiredAccess,
    uint32_t dwShareMode,
    void* lpSecurityAttributes,
    uint32_t dwCreationDisposition,
    uint32_t dwFlagsAndAttributes,
    void* hTemplateFile);
C, "KERNEL32.dll");
// $ffi->CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile);
// lpFileName : LPCWSTR
// 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.UNICODE_OPTIONS);
    Pointer CreateFileW(
        WString lpFileName,   // LPCWSTR
        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
    );
}
// Unicode(-W): WString(入力)/char[](出力)で UTF-16 をマーシャリング。
@[Link("kernel32")]
lib LibKERNEL32
  fun CreateFileW = CreateFileW(
    lpFileName : UInt16*,   # LPCWSTR
    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 CreateFileWNative = Pointer<Void> Function(Pointer<Utf16>, Uint32, Uint32, Pointer<Void>, Uint32, Uint32, Pointer<Void>);
typedef CreateFileWDart = Pointer<Void> Function(Pointer<Utf16>, int, int, Pointer<Void>, int, int, Pointer<Void>);
final CreateFileW = DynamicLibrary.open('KERNEL32.dll')
    .lookupFunction<CreateFileWNative, CreateFileWDart>('CreateFileW');
// lpFileName : LPCWSTR -> Pointer<Utf16>
// 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 CreateFileW(
  lpFileName: PWideChar;   // LPCWSTR
  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 'CreateFileW';
import Foreign
import Foreign.C.Types
import Foreign.C.String

foreign import stdcall safe "CreateFileW"
  c_CreateFileW :: CWString -> Word32 -> Word32 -> Ptr () -> Word32 -> Word32 -> Ptr () -> IO (Ptr ())
-- lpFileName : LPCWSTR -> CWString
-- 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 createfilew =
  foreign "CreateFileW"
    ((ptr uint16_t) @-> uint32_t @-> uint32_t @-> (ptr void) @-> uint32_t @-> uint32_t @-> (ptr void) @-> returning (ptr void))
(* lpFileName : LPCWSTR -> (ptr uint16_t) *)
(* 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 ("CreateFileW" create-file-w :convention :stdcall) :pointer
  (lp-file-name (:string :encoding :utf-16le))   ; LPCWSTR
  (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 $CreateFileW = Win32::API::More->new('KERNEL32',
    'HANDLE CreateFileW(LPCWSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPVOID lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile)');
# my $ret = $CreateFileW->Call($lpFileName, $dwDesiredAccess, $dwShareMode, $lpSecurityAttributes, $dwCreationDisposition, $dwFlagsAndAttributes, $hTemplateFile);
# lpFileName : LPCWSTR -> LPCWSTR
# 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 を使用。
# Unicode(-W): LPCWSTR/LPWSTR は Win32::API が UTF-16 変換を行う。

関連項目

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