Technology · 실용 가이드
Linux “File name too long”? path, component, data 경계를 먼저 증명하세요
원래 caller와 argument를 고정하고 encoded bytes와 실제 destination limit를 측정해 payload 오용, NAME_MAX, PATH_MAX를 분리합니다.
“File name too long”은 한 가지 진단이 아닙니다. component, 전체 pathname, symlink 해석 중간 path가 한계를 넘을 수 있고 JSON이나 인증서 본문을 filename API에 전달해도 비슷한 오류가 납니다.
일률적인 글자 수로 자르지 말고 object가 data인지 path인지 확인한 뒤 component와 full path bytes를 따로 측정하고 실제 destination을 조회해 증명된 branch만 수정합니다.
원래 caller와 argument를 고정합니다
API, errno, 시간, process, cwd, destination mount, argument의 안전한 표현을 기록하고 secret은 길이와 hash만 남깁니다.
callee가 path, bytes, stream, parsed object 중 무엇을 요구하는지 확인하고 JSON이나 PEM이면 data/parse API를 사용합니다.
bytes를 측정하고 pathname을 나눕니다
실제 path를 failure context에서 absolute로 만들고 각 component를 len(os.fsencode(component))로 측정합니다.
longest component와 full pathname을 분리해 prefix, suffix, extension, encoding, Unicode normalization을 보존합니다.
실제 destination limit를 조회합니다
parent directory에서 getconf NAME_MAX/PATH_MAX 또는 os.pathconf의 PC_NAME_MAX/PC_PATH_MAX를 사용합니다.
network mount, encryption layer, application API의 추가 제한과 symlink resolution도 기록합니다.
증명된 branch만 수정합니다
data 오용은 parser/bytes/stream API로 바꾸고 component 초과는 그 component만 줄이거나 collision-resistant ID를 씁니다.
full path 초과는 관리 가능한 root나 nesting을 줄이고 넓은 OSError catch와 silent truncation을 피합니다.
원래 caller로 다시 실행합니다
같은 input class, process context, cwd, destination에서 create, write, 필요한 fsync, read-back, cleanup을 확인합니다.
API contract, byte length, limit, fix branch, name mapping, acceptance를 기록하고 오류가 이동하면 다시 조사합니다.
