Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

10 KiB

Raw Blame History

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed

title

source_type

url

archive_url

status

confidence

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 본문 표현은 미세하게 다를 수 있음.

같은 주제 다른 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

10 KiB Raw Blame History

JDK 21 — Files.createTempFile (공식 javadoc)