CreateFileA 함수(fileapi.h)
파일 또는 I/O 디바이스를 만들거나 엽니다. 가장 일반적으로 사용되는 I/O 디바이스는 파일, 파일 스트림, 디렉터리, 물리적 디스크, 볼륨, 콘솔 버퍼, 테이프 드라이브, 통신 리소스, 메일 슬롯 및 파이프입니다. 함수는 파일 또는 디바이스 및 지정된 플래그 및 특성에 따라 다양한 형식의 I/O에 대한 파일 또는 디바이스에 액세스하는 데 사용할 수 있는 핸들을 반환합니다.
트랜잭션된 I/O에 사용할 수 있는 핸들을 생성하는 트랜잭션 작업으로 이 작업을 수행하려면 CreateFileTransacted 함수를 사용합니다.
구문
HANDLE CreateFileA(
[in] LPCSTR lpFileName,
[in] DWORD dwDesiredAccess,
[in] DWORD dwShareMode,
[in, optional] LPSECURITY_ATTRIBUTES lpSecurityAttributes,
[in] DWORD dwCreationDisposition,
[in] DWORD dwFlagsAndAttributes,
[in, optional] HANDLE hTemplateFile
);
매개 변수
[in] lpFileName
만들거나 열 파일 또는 디바이스의 이름입니다. 이 이름에는 슬래시(/) 또는 백슬래시(\)를 사용할 수 있습니다.
기본적으로 이름은 MAX_PATH 문자로 제한됩니다. 이 제한을 32,767자로 확장하려면 경로에 "\\?\"를 앞에 추가합니다. 자세한 내용은 파일 이름 지정, 경로 및 네임스페이스를 참조하세요.
팁
Windows 10 버전 1607부터 "\\?\"를 앞에 추가하지 않고 MAX_PATH 제한을 제거하도록 옵트인할 수 있습니다. 자세한 내용은 파일, 경로 및 네임스페이스의 "최대 경로 길이 제한" 섹션을 참조하세요.
특수 디바이스 이름에 대한 자세한 내용은 MS-DOS 디바이스 이름 정의를 참조하세요.
파일 스트림을 만들려면 파일 이름, 콜론 및 스트림 이름을 지정합니다. 자세한 내용은 파일 스트림을 참조하세요.
[in] dwDesiredAccess
파일 또는 디바이스에 대한 요청된 액세스 권한으로, 읽기, 쓰기, 둘 다 또는 0으로 요약할 수 있습니다.
가장 일반적으로 사용되는 값은 GENERIC_READ, GENERIC_WRITE 또는 둘 다(GENERIC_READ | GENERIC_WRITE)입니다. 자세한 내용은 일반 액세스 권한, 파일 보안 및 액세스 권한, 파일 액세스 권한상수 및 ACCESS_MASK 참조하세요.
이 매개 변수가 0인 경우 애플리케이션은 GENERIC_READ 액세스가 거부된 경우에도 해당 파일 또는 디바이스에 액세스하지 않고 파일, 디렉터리 또는 디바이스 특성과 같은 특정 메타데이터를 쿼리할 수 있습니다.
열려 있는 핸들이 이미 있는 열린 요청에서 dwShareMode 매개 변수로 지정된 공유 모드와 충돌하는 액세스 모드를 요청할 수 없습니다.
자세한 내용은 이 항목의 설명 섹션 및 파일 만들기 및 열기를 참조하세요.
[in] dwShareMode
파일 또는 디바이스의 요청된 공유 모드로, 읽기, 쓰기, 모두, 삭제, 모두 또는 없음(다음 표 참조)입니다. 특성 또는 확장 특성에 대한 액세스 요청은 이 플래그의 영향을 받지 않습니다.
이 매개 변수가 0이고 CreateFile 이 성공하면 파일 또는 디바이스를 공유할 수 없으며 파일 또는 디바이스에 대한 핸들이 닫혀 있을 때까지 다시 열 수 없습니다. 자세한 내용은 주의 섹션을 참조하세요.
열린 핸들이 있는 기존 요청에 지정된 액세스 모드와 충돌하는 공유 모드를 요청할 수 없습니다. CreateFile 이 실패하고 GetLastError 함수가 ERROR_SHARING_VIOLATION 반환합니다.
다른 프로세스에 파일 또는 디바이스가 열려 있는 동안 프로세스에서 파일 또는 디바이스를 공유할 수 있도록 하려면 다음 값 중 하나 이상의 호환 가능한 조합을 사용합니다. 이 매개 변수와 dwDesiredAccess 매개 변수의 유효한 조합에 대한 자세한 내용은 파일 만들기 및 열기를 참조하세요.
[in, optional] lpSecurityAttributes
별도의 두 개의 관련 데이터 멤버인 선택적 보안 설명자 및 반환된 핸들을 자식 프로세스에서 상속할 수 있는지 여부를 결정하는 부울 값이 포함된 SECURITY_ATTRIBUTES 구조체에 대한 포인터입니다.
이 매개 변수는 NULL일 수 있습니다.
이 매개 변수가 NULL인 경우 CreateFile 에서 반환된 핸들은 애플리케이션이 만들 수 있는 자식 프로세스에서 상속할 수 없으며 반환된 핸들과 연결된 파일 또는 디바이스는 기본 보안 설명자를 가져옵니다.
구조체의 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를 참조하세요. 해당 값과 설명이 포함된 모든 파일 특성의 전체 목록은 파일 특성 상수를 참조하세요.
| attribute | 의미 |
|---|---|
|
파일을 보관해야 합니다. 애플리케이션은 이 특성을 사용하여 파일을 백업 또는 제거로 표시합니다. |
|
파일이나 디렉터리가 암호화되어 있습니다. 파일의 경우 파일의 모든 데이터가 암호화됨을 의미합니다. 디렉터리의 경우 암호화가 새로 만든 파일 및 하위 디렉터리의 기본값임을 의미합니다. 자세한 내용은 파일 암호화를 참조하세요.
FILE_ATTRIBUTE_SYSTEM 지정한 경우에도 이 플래그는 적용되지 않습니다. 이 플래그는 Windows의 Home, Home Premium, Starter 또는 ARM 버전에서 지원되지 않습니다. |
|
파일이 숨겨집니다. 일반 디렉터리 목록에 포함하지 마세요. |
|
파일에 다른 특성이 설정되어 있지 않습니다. 이 특성은 단독으로 사용될 때만 유효합니다. |
|
파일의 데이터를 즉시 사용할 수 없습니다. 이 특성은 파일 데이터가 오프라인 스토리지로 물리적으로 이동되었음을 나타냅니다. 이 특성은 계층적 스토리지 관리 소프트웨어인 Remote Storage에서 사용됩니다. 애플리케이션이 이 특성을 임의로 변경해서는 안 됩니다. |
|
파일은 읽기 전용입니다. 애플리케이션은 파일을 읽을 수 있지만 파일을 쓰거나 삭제할 수는 없습니다. |
|
파일의 일부이거나 운영 체제에서만 사용됩니다. |
|
파일이 임시 스토리지에 사용되고 있습니다.
자세한 내용은 이 항목의 캐싱 동작 섹션을 참조하세요. |
| 플래그 | 의미 |
|---|---|
|
백업 또는 복원 작업을 위해 파일을 열거나 만듭니다. 시스템은 프로세스에 SE_BACKUP_NAME 및SE_RESTORE_NAME 권한이 있는 경우 호출 프로세스가 파일 보안 검사를 재정의하도록 합니다. 자세한 내용은 토큰의 권한 변경을 참조하세요.
디렉터리에 대한 핸들을 가져오려면 이 플래그를 설정해야 합니다. 디렉터리 핸들은 파일 핸들 대신 일부 함수에 전달할 수 있습니다. 자세한 내용은 주의 섹션을 참조하세요. |
|
이 파일은 지정된 핸들과 다른 열린 핸들이나 중복 핸들을 포함하여 모든 핸들이 닫힌 직후 삭제됩니다.
파일에 대한 기존 열린 핸들이 있는 경우 FILE_SHARE_DELETE 공유 모드로 열려 있지 않으면 호출이 실패합니다. FILE_SHARE_DELETE 공유 모드가 지정되지 않은 경우에는 파일에 대한 후속 열기 요청이 실패합니다. |
|
파일 또는 디바이스가 데이터 읽기 및 쓰기에 대한 시스템 캐싱 없이 열리고 있습니다. 이 플래그는 하드 디스크 캐싱 또는 메모리 매핑된 파일에 영향을 주지 않습니다.
FILE_FLAG_NO_BUFFERING 플래그를 사용하여 CreateFile에서 열린 파일을 성공적으로 사용하기 위한 엄격한 요구 사항이 있습니다. 자세한 내용은 파일 버퍼링을 참조하세요. |
|
파일 데이터가 요청되지만 원격 스토리지에 계속 위치해야 합니다. 로컬 스토리지로 다시 전송해서는 안 됩니다. 이 플래그는 원격 스토리지 시스템에서 사용하기 위한 것입니다. |
|
일반적인 재문 분석 지점 처리는 발생하지 않습니다. CreateFile 은 재분석 지점을 열려고 시도합니다. 파일을 열면 재분석 지점을 제어하는 필터가 작동하는지 여부에 관계없이 파일 핸들이 반환됩니다.
이 플래그는 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의 일부로 SECURITY_SQOS_PRESENT 플래그를 지정하는 경우 다음 값 중 하나 이상을 포함할 수도 있습니다.
[in, optional] hTemplateFile
GENERIC_READ 액세스 권한이 있는 템플릿 파일에 대한 유효한 핸들입니다. 템플릿 파일은 생성되는 파일에 대한 파일 특성 및 확장 특성을 제공합니다.
이 매개 변수는 NULL일 수 있습니다.
기존 파일을 열 때 CreateFile 은 이 매개 변수를 무시합니다.
암호화된 새 파일을 열 때 파일은 부모 디렉터리에서 임의 액세스 제어 목록을 상속합니다. 자세한 내용은 파일 암호화를 참조하세요.
반환 값
함수가 성공하면 반환 값은 지정된 파일, 디바이스, 명명된 파이프 또는 메일 슬롯에 대한 열린 핸들입니다.
함수가 실패하는 경우 반환 값은 INVALID_HANDLE_VALUE입니다. 확장 오류 정보를 가져오려면 GetLastError를 호출합니다.
설명
CreateFile 은 원래 파일 상호 작용을 위해 특별히 개발되었지만 이후 Windows 개발자가 사용할 수 있는 대부분의 다른 유형의 I/O 디바이스 및 메커니즘을 포함하도록 확장되고 향상되었습니다. 이 섹션에서는 개발자가 다양한 컨텍스트 및 다른 I/O 형식으로 CreateFile 을 사용할 때 발생할 수 있는 다양한 문제를 다룹니다. 텍스트는 파일 시스템의 실제 파일에 저장된 데이터를 구체적으로 참조할 때만 단어 파일을 사용하려고 합니다. 그러나 파일의 일부 사용은 파일 과 유사한 메커니즘을 지원하는 I/O 개체를 더 일반적으로 참조할 수 있습니다. 이 용어 파일 의 자유로운 사용은 이전에 언급한 기록상의 이유로 인해 상수 이름 및 매개 변수 이름에 특히 널리 퍼집니다.
CreateFile에서 반환된 개체 핸들을 사용하여 애플리케이션이 완료되면 CloseHandle 함수를 사용하여 핸들을 닫습니다. 이렇게 하면 시스템 리소스를 확보할 수 있을 뿐만 아니라 파일 또는 디바이스 공유 및 디스크에 데이터 커밋과 같은 항목에 더 큰 영향을 미칠 수 있습니다. 세부 정보는 이 항목 내에서 적절하게 설명됩니다.
Windows Server 2003 및 Windows XP: dwDesiredAccess 매개 변수 값이 다른 액세스 플래그가 있는 DELETE 액세스 플래그(0x00010000) OR'ed이고 원격 파일 또는 디렉터리가 FILE_SHARE_DELETE 열려 있지 않은 경우 원격 컴퓨터에서 삭제를 위해 파일 또는 디렉터리를 열려고 하면 공유 위반이 발생합니다. 이 시나리오에서 공유 위반을 방지하려면 DELETE 액세스 권한으로만 원격 파일 또는 디렉터리를 열거나 삭제를 위해 파일 또는 디렉터리를 먼저 열지 않고 DeleteFile 을 호출합니다.
NTFS 파일 시스템과 같은 일부 파일 시스템은 개별 파일 및 디렉터리에 대한 압축 또는 암호화를 지원합니다. 이 지원을 통해 탑재된 파일 시스템이 있는 볼륨에서 새 파일은 해당 디렉터리의 압축 및 암호화 특성을 상속합니다.
CreateFile을 사용하여 파일 또는 디렉터리에 대한 압축, 압축 해제 또는 암호 해독을 제어할 수 없습니다. 자세한 내용은 파일 만들기 및 열기, 파일 압축 및 압축 해제 및파일 암호화를 참조하세요.
Windows Server 2003 및 Windows XP: 이전 버전과의 호환성을 위해 CreateFile 은 lpSecurityAttributes에서 보안 설명자를 지정할 때 상속 규칙을 적용하지 않습니다. 상속을 지원하기 위해 나중에 이 파일의 보안 설명자를 쿼리하는 함수는 상속이 적용되는지 추론적으로 확인하고 보고할 수 있습니다. 자세한 내용은 상속 가능한 ACE의 자동 전파를 참조하세요.
앞에서 설명한 대로 lpSecurityAttributes 매개 변수가 NULL인 경우 CreateFile 에서 반환된 핸들은 애플리케이션이 만들 수 있는 자식 프로세스에서 상속할 수 없습니다. 이 매개 변수에 대한 다음 정보도 적용됩니다.
- bInheritHandle 멤버 변수가 0이 아닌 값인 FALSE가 아니면 핸들을 상속할 수 있습니다. 따라서 핸들을 상속할 수 없도록 하려면 이 구조체 멤버를 FALSE 로 올바르게 초기화해야 합니다.
- 파일 또는 디렉터리에 대한 기본 보안 설명자의 ACL(액세스 제어 목록)은 부모 디렉터리에서 상속됩니다.
- 대상 파일 시스템은 lpSecurityDescriptor 멤버가 영향을 주도록 파일 및 디렉터리에 대한 보안을 지원해야 하며, GetVolumeInformation을 사용하여 확인할 수 있습니다.
| 기술 | 지원됨 |
|---|---|
| SMB(서버 메시지 블록) 3.0 프로토콜 | Yes |
| SMB 3.0 TFO(투명 장애 조치(failover)) | 설명 보기 |
| SO(스케일 아웃 파일 공유)를 사용하는 SMB 3.0 | 설명 보기 |
| CsvFS(클러스터 공유 볼륨 파일 시스템) | Yes |
| ReFS(Resilient File System) | Yes |
대체 처리가 있는 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가 지정된 경우, 영향을 받는 파일이 대상입니다.
캐싱 동작
dwFlagsAndAttributes 매개 변수에 사용할 수 있는 몇 가지 값은 CreateFile에서 핸들과 연결된 데이터가 시스템에서 캐시되는 방식을 제어하거나 영향을 미치는 데 사용됩니다. 아래에 이 계정과 키의 예제가 나와 있습니다.- FILE_FLAG_NO_BUFFERING
- FILE_FLAG_RANDOM_ACCESS
- FILE_FLAG_SEQUENTIAL_SCAN
- FILE_FLAG_WRITE_THROUGH
- FILE_ATTRIBUTE_TEMPORARY
이러한 플래그 중 일부는 결합해서는 안 됩니다. instance 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_BUFFERINGFILE_FLAG_OVERLAPPED 결합하면 I/O가 메모리 관리자의 동기 작업에 의존하지 않으므로 플래그는 최대 비동기 성능을 제공합니다. 그러나 데이터가 캐시에 저장되지 않으므로 일부 I/O 작업에는 더 많은 시간이 소요됩니다. 또한 파일 메타데이터는 여전히 캐시될 수 있습니다(예: 빈 파일을 만들 때). 메타데이터가 디스크로 플러시되도록 하려면 FlushFileBuffers 함수를 사용합니다.
FILE_ATTRIBUTE_TEMPORARY 특성을 지정하면 핸들이 닫힌 후 애플리케이션이 임시 파일을 삭제하기 때문에 충분한 캐시 메모리를 사용할 수 있는 경우 파일 시스템에서 대량 스토리지에 데이터를 다시 쓰지 않도록 합니다. 이 경우 시스템은 데이터 쓰기를 완전히 방지할 수 있습니다. 앞에서 언급한 플래그와 동일한 방식으로 데이터 캐싱을 직접 제어하지는 않지만 , FILE_ATTRIBUTE_TEMPORARY 특성은 시스템에서 작성하지 않고 시스템 캐시에 가능한 한 많이 보유하도록 지시하므로 특정 애플리케이션에 문제가 될 수 있습니다.
파일
파일 이름을 바꾸거나 삭제한 다음 잠시 후에 복원하는 경우 시스템은 복원할 파일 정보를 캐시에 검색합니다. 캐시된 정보에는 짧은/긴 이름 쌍 및 생성 시간이 포함됩니다.DeleteFile에 대한 이전 호출의 결과로 삭제 보류 중인 파일에서 CreateFile을 호출하면 함수가 실패합니다. 운영 체제는 파일에 대한 모든 핸들을 닫을 때까지 파일 삭제를 지연합니다. GetLastError는ERROR_ACCESS_DENIED 반환합니다.
dwDesiredAccess 매개 변수는 0일 수 있으므로 애플리케이션이 적절한 보안 설정으로 실행 중인 경우 파일에 액세스하지 않고 파일 특성을 쿼리할 수 있습니다. 읽기 및/또는 쓰기 액세스를 위해 파일을 열지 않고 파일이 있는지 테스트하거나 파일 또는 디렉터리에 대한 다른 통계를 가져오는 데 유용합니다. 파일 정보 가져오기 및 설정 및 GetFileInformationByHandle을 참조하세요.
CREATE_ALWAYS 및 FILE_ATTRIBUTE_NORMAL 지정하면 CreateFile이 실패하고 파일이 있고 FILE_ATTRIBUTE_HIDDEN 또는FILE_ATTRIBUTE_SYSTEM 특성이 있는 경우 마지막 오류를 ERROR_ACCESS_DENIED 설정합니다. 오류를 방지하려면 기존 파일과 동일한 특성을 지정합니다.
애플리케이션이 네트워크를 통해 파일을 만드는 경우 GENERIC_WRITE 단독으로 사용하는 것보다 dwDesiredAccess에 사용하는 GENERIC_READ | GENERIC_WRITE 것이 좋습니다. 리다이렉터에서 캐시 관리자를 사용하고 더 많은 데이터로 더 적은 SMB를 보낼 수 있으므로 결과 코드가 더 빠릅니다.
또한 이 조합은 네트워크를 통해 파일에 쓰는 경우 때때로 ERROR_ACCESS_DENIED 반환할 수 있는 문제를 방지합니다.
자세한 내용은 파일 만들기 및 열기를 참조하세요.
동기 및 비동기 I/O 핸들
CreateFile 은 동기 또는 비동기 파일 또는 디바이스 핸들을 만드는 데 제공합니다. 동기 핸들은 해당 핸들을 사용하여 I/O 함수 호출이 완료될 때까지 차단되도록 동작하지만, 비동기 파일 핸들을 사용하면 I/O 작업을 완료했는지 여부에 관계없이 시스템이 I/O 함수 호출에서 즉시 반환할 수 있습니다. 앞에서 설명한 대로 이 동기 및 비동기 동작은 dwFlagsAndAttributes 매개 변수 내에서 FILE_FLAG_OVERLAPPED 지정하여 결정됩니다. 비동기 I/O를 사용하는 경우 몇 가지 복잡성 및 잠재적인 문제가 있습니다. 자세한 내용은 동기 및 비동기 I/O를 참조하세요.파일 스트림
NTFS 파일 시스템에서 CreateFile 을 사용하여 파일 내에 별도의 스트림을 만들 수 있습니다. 자세한 내용은 파일 스트림을 참조하세요.디렉터리
애플리케이션은 CreateFile을 사용하여 디렉터리를 만들 수 없으므로 이 사용 사례의 dwCreationDisposition에는 OPEN_EXISTING 값만 유효합니다. 디렉터리를 만들려면 애플리케이션에서 CreateDirectory 또는 CreateDirectoryEx를 호출해야 합니다.CreateFile을 사용하여 디렉터리를 열려면 dwFlagsAndAttributes의 일부로 FILE_FLAG_BACKUP_SEMANTICS 플래그를 지정합니다. 이 플래그를 SE_BACKUP_NAME 및 SE_RESTORE_NAME 권한 없이 사용하는 경우에도 적절한 보안 검사가 계속 적용됩니다.
CREATEFile을 사용하여 FAT 또는 FAT32 파일 시스템 볼륨을 조각 모음하는 동안 디렉터리를 여는 경우 MAXIMUM_ALLOWED 액세스 권한을 지정하지 마세요. 이 작업을 수행하면 디렉터리에 대한 액세스가 거부됩니다. 대신 GENERIC_READ 액세스를 지정합니다.
자세한 내용은 디렉터리 관리 정보를 참조하세요.
물리적 디스크 및 볼륨
디스크 또는 볼륨에 대한 직접 액세스가 제한됩니다.Windows Server 2003 및 Windows XP: 디스크 또는 볼륨에 대한 직접 액세스는 이러한 방식으로 제한되지 않습니다.
CreateFile 함수를 사용하여 DeviceIoControl 함수와 함께 사용할 수 있는 DASD(직접 액세스 스토리지 디바이스) 핸들을 반환하는 물리적 디스크 드라이브 또는 볼륨을 열 수 있습니다. 이렇게 하면 디스크 또는 볼륨(예: 파티션 테이블과 같은 디스크 메타데이터)에 직접 액세스할 수 있습니다. 그러나 이 유형의 액세스는 디스크 드라이브 또는 볼륨을 잠재적인 데이터 손실에 노출합니다. 이 메커니즘을 사용하여 디스크에 잘못 쓰면 해당 콘텐츠가 운영 체제에 액세스할 수 없게 될 수 있기 때문입니다. 데이터 무결성을 보장하려면 DeviceIoControl 및 파일 시스템 핸들이 아닌 직접 액세스 핸들을 사용하여 다른 API가 다르게 동작하는 방식을 숙지해야 합니다.
이러한 호출이 성공하려면 다음 요구 사항을 충족해야 합니다.
- 호출자에게는 관리 권한이 있어야 합니다. 자세한 내용은 특별 권한으로 실행을 참조하세요.
- dwCreationDisposition 매개 변수에는 OPEN_EXISTING 플래그가 있어야 합니다.
- 볼륨 또는 플로피 디스크를 열 때 dwShareMode 매개 변수에는 FILE_SHARE_WRITE 플래그가 있어야 합니다.
| String | 의미 |
|---|---|
| "\\.\PhysicalDrive0" | 첫 번째 실제 드라이브를 엽니다. |
| "\\.\PhysicalDrive2" | 세 번째 실제 드라이브를 엽니다. |
볼륨에 대한 물리적 드라이브 식별자를 가져오려면 볼륨에 대한 핸들을 열고 IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTSDeviceIoControl 함수를 호출합니다. 이 제어 코드는 각 볼륨의 하나 이상의 익스텐트의 디스크 번호와 오프셋을 반환합니다. 볼륨은 여러 실제 디스크에 걸쳐 있습니다.
물리적 드라이브를 여는 예제는 DeviceIoControl 호출을 참조하세요.
볼륨 또는 이동식 미디어 드라이브(예: 플로피 디스크 드라이브 또는 플래시 메모리 썸 드라이브)를 열 때 lpFileName 문자열은 "\.\X:" 형식이어야 합니다. 드라이브의 루트 디렉터리를 나타내는 후행 백슬래시(\)를 사용하지 마세요. 다음 표에서는 드라이브 문자열의 몇 가지 예를 보여 줍니다.
| String | 의미 |
|---|---|
| "\\.\A:" | 플로피 디스크 드라이브 A를 엽니다. |
| "\\.\C:" | C: 볼륨을 엽니다. |
| "\\.\C:\" | C: 볼륨의 파일 시스템을 엽니다. |
볼륨 이름을 참조하여 볼륨을 열 수도 있습니다. 자세한 내용은 볼륨 이름을 참조하세요.
볼륨에는 하나 이상의 탑재된 파일 시스템이 포함되어 있습니다. 볼륨 핸들은 CreateFile에서 캐시되지 않은 옵션이 지정되지 않은 경우에도 특정 파일 시스템의 재량에 따라 캐시되지 않은 것으로 열 수 있습니다. 모든 Microsoft 파일 시스템이 볼륨 핸들을 캐시되지 않은 것으로 여는 것으로 가정해야 합니다. 파일에 대한 캐시되지 않은 I/O에 대한 제한 사항도 볼륨에 적용됩니다.
데이터가 캐시되지 않더라도 파일 시스템에 버퍼 맞춤이 필요하거나 필요하지 않을 수 있습니다. 그러나 볼륨을 열 때 캐시되지 않은 옵션을 지정하면 볼륨의 파일 시스템에 관계없이 버퍼 맞춤이 적용됩니다. 볼륨 핸들을 캐시되지 않은 것으로 열고 캐시되지 않은 I/O 제한을 따르는 모든 파일 시스템에서 권장됩니다.
Changer Device
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 포트 번호를 지정할 수 있는 모든 포트 번호 및 하드웨어에 대해 작동합니다.
통신에 대한 자세한 내용은 통신을 참조하세요.
콘솔
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 지정합니다.
호출 프로세스가 콘솔을 상속하거나 자식 프로세스가 콘솔에 액세스할 수 있어야 하는 경우 이 매개 변수는 이어야 |
| lpSecurityAttributes | 콘솔을 상속하려면 SECURITY_ATTRIBUTES 구조체의 bInheritHandle 멤버가 TRUE여야 합니다. |
| dwCreationDisposition | CreateFile을 사용하여 콘솔을 열 때 OPEN_EXISTING 지정해야 합니다. |
| dwFlagsAndAttributes | 무시됩니다. |
| hTemplateFile | 무시됩니다. |
다음 표에서는 dwDesiredAccess 및 lpFileName의 다양한 설정을 보여 줍니다.
| lpFileName | dwDesiredAccess | 결과 |
|---|---|---|
| "CON" | GENERIC_READ | 입력할 콘솔을 엽니다. |
| "CON" | GENERIC_WRITE | 출력을 위한 콘솔을 엽니다. |
| "CON" | GENERIC_READ | GENERIC_WRITE |
CreateFile이 실패하도록 합니다. GetLastError는ERROR_FILE_NOT_FOUND 반환합니다. |
메일 슬롯
CreateFile이 mailslot의 클라이언트 끝을 열면 mailslot 클라이언트가 mailslot 서버가 CreateMailSlot 함수를 사용하여 만들기 전에 mailslot 클라이언트가 로컬 mailslot을 열려고 하면 INVALID_HANDLE_VALUE 반환합니다.자세한 내용은 Mailslots를 참조하세요.
파이프
CreateFile이 명명된 파이프의 클라이언트 끝을 열면 함수는 수신 대기 상태에 있는 명명된 파이프의 instance 사용합니다. 여는 프로세스는 필요에 따라 핸들을 여러 번 복제할 수 있지만, 핸들을 연 후에는 명명된 파이프 instance 다른 클라이언트에서 열 수 없습니다. 파이프를 열 때 지정된 액세스는 CreateNamedPipe 함수의 dwOpenMode 매개 변수에 지정된 액세스와 호환되어야 합니다.이 작업 전에 서버에서 CreateNamedPipe 함수가 성공적으로 호출되지 않은 경우 파이프가 존재하지 않으며 CreateFile 이 ERROR_FILE_NOT_FOUND 실패합니다.
활성 파이프 instance 하나 이상 있지만 서버에 사용 가능한 수신기 파이프가 없으면 모든 파이프 인스턴스가 현재 연결되어 있으므로 CreateFile이 ERROR_PIPE_BUSY 실패합니다.
자세한 내용은 파이프를 참조하세요.
예제
예제 파일 작업은 다음 topics 나와 있습니다.
- 한 파일을 다른 파일에 추가
- 보류 중인 I/O 작업 취소
- 리디렉션된 입력 및 출력을 사용하여 하위 프로세스 만들기
- 임시 파일 만들기 및 사용
- FSCTL_RECALL_FILE
- GetFinalPathNameByHandle
- 파일에서 바이트 범위 잠금 및 잠금 해제
- 파일 핸들에서 파일 이름 가져오기
- 파일 시스템 인식 정보 가져오기
- 읽기 또는 쓰기용으로 파일 열기
- Last-Write 시간 검색
- SetFileInformationByHandle
- 파일의 끝 테스트
- 파이버 사용
- 스트림 사용
- 변경 저널 레코드 버퍼 안내
- Wow64DisableWow64FsRedirection
- Wow64EnableWow64FsRedirection
mailslot으로 작업하는 것은 Mailslot에 쓰기에 표시됩니다.
테이프 백업 코드 조각은 백업 애플리케이션 만들기에서 찾을 수 있습니다.
참고
fileapi.h 헤더는 CREATEFile을 유니코드 전처리기 상수의 정의에 따라 이 함수의 ANSI 또는 유니코드 버전을 자동으로 선택하는 별칭으로 정의합니다. 인코딩 중립 별칭을 인코딩 중립이 아닌 코드와 혼합하면 컴파일 또는 런타임 오류가 발생하는 불일치가 발생할 수 있습니다. 자세한 내용은 함수 프로토타입에 대한 규칙을 참조하세요.
요구 사항
| 지원되는 최소 클라이언트 | Windows XP [데스크톱 앱만 해당] |
| 지원되는 최소 서버 | Windows Server 2003 [데스크톱 앱만 해당] |
| 대상 플랫폼 | Windows |
| 헤더 | fileapi.h(Windows.h 포함) |
| 라이브러리 | Kernel32.lib |
| DLL | Kernel32.dll |
참고 항목
함수
개요 항목
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기