Files
llm-wiki/raw/official-docs/jdk-files-createtempfile.md
T

99 lines
10 KiB
Markdown

---
title: JDK 21 — java.nio.file.Files.createTempFile (official-vendor-doc)
source_type: official-doc
url: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/Files.html
archive_url:
status: raw
confidence: high
tags: [java, jdk21, nio, files, tempfile, file-resource-handling-contract, security]
related_projects: []
related_branches: [feature-file-resource-handling-contract]
created: 2026-05-27
last_reviewed: 2026-05-27
---
# JDK 21 — `Files.createTempFile` (공식 javadoc)
> Layer: `raw/official-docs/` — Oracle JDK 21 javadoc 의 **원문 발췌·출처 기록**.
> Strength 분류: `official-vendor-doc` — Oracle JDK 21 의 공식 API reference.
> 검증된 요약은 `/ingest` 후 `wiki/concepts/` 에 별도 작성.
## Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-file-resource-handling-contract]] | **D6 (temp file cleanup mechanism)** 의 근거 — JDK 가 공식 제공하는 cleanup 옵션(`DELETE_ON_CLOSE`, shutdown hook, `File.deleteOnExit`) 의 표준 명세. temp 파일 생성·정리 책임을 명문화하는 contract 의 외부 근거. |
## 컨텍스트
`feature-file-resource-handling-contract` 의 D6 은 "temp 파일은 생성과 동시에 cleanup 책임이 정의되어야 한다" 는 contract 를 다룬다. JDK `Files.createTempFile` 의 javadoc 은 (a) default temp directory 동작, (b) prefix/suffix 규칙, (c) FileAttribute 권한 옵션, (d) cleanup 메커니즘 3가지(`DELETE_ON_CLOSE` / shutdown hook / `File.deleteOnExit`) 를 직접 진술한다. 본 raw 는 D6 의 외부 근거로 보관.
## 출처 / Source
- 원본 URL: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/Files.html
- 검색 anchor: `createTempFile` (page 내 method 섹션)
- 아카이브 URL: (미수집 — 추후 archive.org 스냅샷 추가)
- 저자 / 조직: Oracle / OpenJDK — `java.base` module `java.nio.file.Files` class
- 발행일: JDK 21 GA (2023-09-19) / javadoc 은 LTS 동안 유지보수
- 마지막 확인일: 2026-05-27
## 핵심 인용 / Key quotes (verbatim)
> [§createTempFile(Path, String, String, FileAttribute<?>...)] "public static Path createTempFile(Path dir, String prefix, String suffix, FileAttribute<?>... attrs) throws IOException"
> [§createTempFile(String, String, FileAttribute<?>...)] "public static Path createTempFile(String prefix, String suffix, FileAttribute<?>... attrs) throws IOException"
> [§createTempFile — 3-arg description] "Creates an empty file in the default temporary-file directory, using the given prefix and suffix to generate its name."
> [§createTempFile — prefix param] "the prefix string to be used in generating the file's name; may be null"
> [§createTempFile — suffix param] "the suffix string to be used in generating the file's name; may be null, in which case \".tmp\" is used"
> [§createTempFile — FileAttribute] "Each attribute is identified by its name. If more than one attribute of the same name is included in the array then all but the last occurrence is ignored."
> [§createTempFile — permissions note] "When no file attributes are specified, then the resulting file may have more restrictive access permissions to files created by the File.createTempFile(String,String,File) method."
> [§createTempFile — cleanup recommendation] "As with the createTempFile methods, this method is only part of a temporary-file facility. Where used as a work file, the resulting file may be opened using the DELETE_ON_CLOSE option so that the file is deleted when the appropriate close method is invoked."
> [§createTempFile — alternative cleanup] "Alternatively, a shutdown-hook, or the File.deleteOnExit() mechanism may be used to delete the file automatically."
## Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| JDK-TEMPFILE-C1 | `Files.createTempFile` 은 두 가지 overload — `(Path dir, String prefix, String suffix, FileAttribute<?>...)``(String prefix, String suffix, FileAttribute<?>...)` — 를 제공한다 | [§signature] "public static Path createTempFile(Path dir, String prefix, String suffix, FileAttribute<?>... attrs) throws IOException" + "public static Path createTempFile(String prefix, String suffix, FileAttribute<?>... attrs) throws IOException" | `official-vendor-doc` | JDK 21 의 `java.nio.file.Files` API | 다른 JDK 버전 (8/11/17) 에서도 동일 시그니처라는 보장은 본 문서가 직접 주지 않음 (LTS 일관성은 별도 확인) |
| JDK-TEMPFILE-C2 | 3-arg overload 는 **default temporary-file directory** 에 빈 파일을 생성한다 | [§3-arg description] "Creates an empty file in the default temporary-file directory, using the given prefix and suffix to generate its name." | `official-vendor-doc` | `createTempFile(prefix, suffix, attrs)` 호출 시나리오 | default temp directory 의 OS별 위치 (Linux `/tmp`, Windows `%TEMP%` 등) 는 본 javadoc 의 직접 인용 범위 밖 — `java.io.tmpdir` system property 참조 |
| JDK-TEMPFILE-C3 | `prefix` 는 null 가능, `suffix` 는 null 일 경우 `.tmp` 가 사용된다 | [§prefix/suffix] "the prefix string to be used in generating the file's name; may be null" + "may be null, in which case \".tmp\" is used" | `official-vendor-doc` | `Files.createTempFile` 호출 시 인자 처리 | prefix=null 일 때의 default 문자열 정책은 본 인용 범위에 명시 없음 (구현 의존) |
| JDK-TEMPFILE-C4 | `FileAttribute<?>...` 배열에서 동일 name 의 attribute 가 중복되면 **마지막 항목만 적용** 되고 나머지는 무시된다 | [§FileAttribute] "If more than one attribute of the same name is included in the array then all but the last occurrence is ignored." | `official-vendor-doc` | FileAttribute 배열 중복 처리 | 어떤 attribute name 들이 표준 정의되어 있는지(예: `posix:permissions`) 는 본 인용에 없음 — 별도 javadoc 참조 |
| JDK-TEMPFILE-C5 | **file attribute 를 지정하지 않으면**, 결과 파일은 `File.createTempFile(String,String,File)` (구 API) 으로 생성한 파일보다 **더 제한적인** 접근 권한을 가질 **수 있다** ("may have") | [§permissions note] "When no file attributes are specified, then the resulting file may have more restrictive access permissions…" | `official-vendor-doc` | 보안 측면에서 `java.io.File.createTempFile` vs `java.nio.file.Files.createTempFile` 선택 | "항상 더 제한적" 이라는 보장은 아님 (원문 "may have") — OS / FileSystem provider 에 따라 실제 권한은 다름. POSIX 의 정확한 mode bit (예: 0600) 는 본 인용으로 보장 안 됨 |
| JDK-TEMPFILE-C6 | `createTempFile` 은 temp file facility 의 일부일 뿐이며, work file 로 사용 시 **`DELETE_ON_CLOSE` 옵션** 으로 열어 close 시 자동 삭제 가능 | [§cleanup] "Where used as a work file, the resulting file may be opened using the DELETE_ON_CLOSE option so that the file is deleted when the appropriate close method is invoked." | `official-vendor-doc` | temp file 의 lifecycle 관리 (open ~ close) | `DELETE_ON_CLOSE` 가 모든 FileSystem provider 에서 atomic 하다는 보장은 아님 (분산 FS 등은 별도) |
| JDK-TEMPFILE-C7 | 대안 cleanup 메커니즘: **shutdown-hook** 또는 **`File.deleteOnExit()`** 를 사용해 자동 삭제 가능 | [§alternative cleanup] "Alternatively, a shutdown-hook, or the File.deleteOnExit() mechanism may be used to delete the file automatically." | `official-vendor-doc` | JVM 종료 시점 cleanup 정책 | `File.deleteOnExit()` 가 abnormal JVM termination(SIGKILL 등) 에서도 동작한다는 보장은 아님 (JVM 정상 종료 path 의존) — 본 raw 가 직접 보증하지 않음 |
## Usage Boundaries / 적용 경계
- **이 자료가 직접 증명하는 것**:
- `JDK-TEMPFILE-C1`, `C2`, `C3`: API 시그니처와 default 동작
- `JDK-TEMPFILE-C6`, `C7`: cleanup 옵션 3가지 — `DELETE_ON_CLOSE`, shutdown hook, `File.deleteOnExit()` — 가 공식 제공됨
- `JDK-TEMPFILE-C5`: 보안 측면에서 `Files.createTempFile` 이 기존 `File.createTempFile` 보다 더 제한적 권한을 가질 **가능성** (보장 아님)
- **이 자료가 증명하지 않는 것**:
- **POSIX 환경에서 default 권한이 정확히 0600** 이라는 점 — 본 javadoc 은 "may have more restrictive" 만 명시 (`C5`). 정확한 mode bit 보장은 OpenJDK 소스 또는 POSIX provider 구현 확인 필요
- **`File.deleteOnExit()` 의 abnormal termination 시 동작** — `C7` 은 mechanism 의 존재만 진술, 신뢰성 보장은 아님
- **Spring 의 `MultipartFile.transferTo()` 가 내부적으로 `Files.createTempFile` 을 사용한다는 점** — Spring 측 코드 / javadoc 별도 확인 필요
- **default temp directory 의 OS별 경로** (`java.io.tmpdir` system property 의 default 는 별도 문서)
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
- `feature-file-resource-handling-contract` 의 D6 cleanup 전략이 위 3가지 중 어느 것을 채택할지 — try-with-resources + `DELETE_ON_CLOSE` 가 일반적으로 권장되나, 본 raw 는 권장도까지 진술하지 않음 (해석은 wiki/concepts 의 source-summary 에서)
- container 환경에서 default temp directory 가 read-only FS 인 경우 (예: GKE/EKS read-only root) 의 동작 — `Path dir` 명시 overload (`C1`) 사용 필요. 본 raw 의 직접 증명 범위 밖
## 메모 / Notes
- `C5` 의 "may have more restrictive" 문구는 **보장이 아니다**. wiki/concepts 옮길 때 "POSIX 0600 보장" 같은 강한 진술 금지.
- `C7``File.deleteOnExit()`**memory leak 위험**(등록된 path 가 JVM lifetime 동안 collection 에 누적) 이 별도 javadoc 에 명시되어 있음 — 본 raw 는 그 부분을 직접 인용하지 않았으므로, 권장도 평가 시 별도 출처 확인.
- JDK 17 / JDK 25 등 다른 LTS 버전의 시그니처 동일성은 별도 확인 — LTS 간 source-compatible 가정이지만 javadoc 본문 표현은 미세하게 다를 수 있음.
## Related / 관련
- 같은 주제 다른 raw 자료: (현재 없음 — 추후 Spring `MultipartFile` javadoc / Apache Commons IO `FileCleaningTracker` 보강 시 추가)
- 이 자료를 인용한 wiki 요약: (미작성)
- 이 자료를 인용하는 branch: [[raw/branch-notes/feature-file-resource-handling-contract]]
- 인용하는 project: [[raw/project-notes/ca-skeleton-operational-contract]]