Windows 11에서는 공백과 이모지로 채운 200자 길이의 파일 이름도 사용할 수 있지만, 파일 탐색기에서는 파일이나 폴더의 이름을 CON으로 지정할 수 없습니다. CON, PRN, AUX, NUL, COM1~COM9, LPT1~LPT9는 예약된 장치 이름입니다. MS 엔지니어 Raymond Chen은 그 기원이 폴더조차 지원하지 않았던 DOS 1.0까지 거슬러 올라간다고 설명합니다.

Windows 11 26H2가 실행되는 PC에서 이 규칙을 테스트했습니다. 1981년 운영체제에서 도입된 제한은 여전히 확고하게 유지되고 있지만, Windows Latest는 그중 일부가 더 이상 MS 문서의 설명대로 작동하지 않는다는 사실을 확인했습니다.

Windows 11에서 CON, PRN, AUX, NUL은 파일 이름이 아닌 장치입니다

각 예약 이름은 하나의 장치에 해당합니다. 특히 NUL은 주목할 만합니다. NUL은 전송된 모든 내용을 폐기하는 블랙홀처럼 작동합니다.

MS의 파일 이름 지정 문서는 여전히 개발자들에게 “파일 이름에 다음 예약 이름을 사용하지 마십시오.”라고 안내합니다. Windows는 폴더를 특수한 유형의 파일로 취급하므로 이러한 제한은 폴더에도 적용됩니다.

MS에 따르면 확장자를 추가해도 제한을 우회할 수 없어야 하지만, 일부 경우에는 우회가 가능합니다. MS는 “NUL.txt와 NUL.tar.gz는 모두 NUL과 동일합니다.”라고 설명합니다. 위 첨자 숫자도 예외가 아닙니다. Windows는 ¹, ², ³을 숫자로 해석하므로 COM¹, LPT³ 같은 이름은 “모든 디렉터리에서” 예약되어 있습니다.

아키텍처상 COM1은 Windows 커널 내부의 직렬 포트로 연결되는 링크입니다. MS는 이를 MS-DOS 장치 이름이라고 부르므로 COM1을 입력하면 파일이 아니라 해당 포트에 접근하게 됩니다.

Raymond Chen이 DOS 1.0 규칙이 Windows 11에서도 유지되는 이유를 설명합니다

이 이야기는 MS-DOS가 호환성을 확보하려 했던 운영체제 CP/M에서 시작됩니다. CP/M에서는 CON:처럼 장치 이름에 항상 콜론이 포함되었습니다. MS-DOS는 콜론을 선택 사항으로 만들었고, OS/2 Museum의 Michal Necasek은 이 결정을 “치명적인 결함”이라고 부릅니다. CON 같은 일반 이름만으로는 파일을 가리키는지 콘솔을 가리키는지 DOS가 구분할 수 없습니다.

Chen은 2003년 자신의 Old New Thing 블로그 게시물에서 “DOS 1.0은 하위 디렉터리와 소문자, 그리고 8.3 형식보다 긴 파일 이름을 지원하지 않았습니다.”라고 설명했습니다. 이러한 제한은 Windows 11의 가장 오래된 일부 시스템 파일이 DOS 시대의 이름을 유지하고 있는 특이한 이유이기도 합니다.

당시 어셈블러가 출력물을 어디에 저장할지 물었을 때 사용자가 인쇄물을 원한다면 “파일 이름으로 ‘PRN’을 입력했습니다.” NUL을 입력하면 출력이 폐기됐고, CON을 입력하면 화면에 표시됐습니다.

디스크에는 디렉터리가 하나뿐이었기 때문에 이러한 특수 이름이 작동할 다른 위치가 없었습니다. 1983년 DOS 2.0에서 폴더가 도입되자 장치 이름도 폴더 내부에서 작동해야 했습니다. Chen의 설명에 따르면, 그렇지 않으면 사용자가 다른 폴더로 이동해 어셈블러를 실행한 다음 NUL을 입력해 출력을 폐기할 수 없었을 것입니다. 이에 MS는 모든 폴더에서 해당 이름이 작동하도록 만들었고, 이것이 오늘날에도 문서 폴더에서 PRN이라는 파일을 만들 수 없는 이유입니다.

MS는 왜 40년이 넘도록 이 동작을 제거하지 않았을까요? Chen은 “모두가 여전히 이에 의존하고 있기 때문입니다.”라고 썼습니다. 배치 파일은 출력을 >NUL로 리디렉션해 표시되지 않도록 하고, 스크립트는 “if exist directoryname\nul”을 사용해 폴더의 존재 여부를 확인하며, 오래된 안내서는 “copy CON”으로 파일을 생성하라고 설명합니다.

이 규칙이 제거되면 출력을 NUL로 리디렉션하는 모든 스크립트가 실제 파일을 쓰기 시작하게 됩니다.

한때 이 규칙은 PC 전체를 충돌시키기도 했습니다. Windows 95와 Windows 98은 장치 이름 하나가 포함된 경로는 거부했지만, C:\con\con처럼 경로에 장치 이름이 두 개 포함되면 오류가 발생했습니다. 2000년 3월에 발표된 MS의 MS00-017 보안 공지는 이 문제가 “일반적으로 시스템 충돌을 초래합니다.”라고 인정했습니다.

Windows 11 26H2에서 DOS 시대 규칙을 테스트했더니 NUL.txt는 허용됐습니다

Windows 11 26H2가 실행되는 PC에서 새 폴더의 이름을 CON으로 변경하자 “지정된 장치 이름이 잘못되었습니다.”라는 메시지가 표시됐습니다. PRN, AUX, NUL, COM1도 거부됐습니다.

하지만 MS 문서에서는 여전히 NUL.txt가 NUL과 동일하다고 설명하고 있음에도 NUL.txt는 오류 없이 허용됐으며, CON.txt도 마찬가지였습니다.

MS 문서는 업데이트되지 않았지만, Python의 Windows 지원을 조사하던 개발자들은 2022년에 Windows 11이 파일 경로를 처리할 때 확장자가 붙은 장치 이름을 더 이상 특수하게 취급하지 않는다는 사실을 확인했습니다.

안타깝게도 이러한 파일은 예측할 수 없는 방식으로 동작할 수 있습니다. MS Q&A의 한 사용자는 PowerShell에서 NUL.txt를 목록에 표시할 수는 있었지만 열거나 삭제할 수는 없었다고 밝혔습니다. 커뮤니티 어드바이저는 “결과를 예측할 수 없을 수 있습니다.”라고 답했습니다. 이는 MS가 확장자가 NUL.txt와 CON.txt 같은 이름에 영향을 주지 않는다고 계속 설명하는 이유일 수 있습니다.

명령 프롬프트에서는 여전히 과거 DOS의 동작을 확인할 수 있습니다. echo hello > CON을 실행하면 파일이 생성되는 대신 화면에 “hello”가 출력됐으며, echo test > COM¹은 MS 문서의 설명과 정확히 일치하게 실패했습니다.

Windows를 비판하기 전에, Linux 유지관리자들이 2024년에 그래픽 드라이버 파일 이름을 aux.c에서 auxch.c로 변경했다는 점도 주목할 필요가 있습니다. 기존 이름 때문에 사용자가 Windows에서 Linux 커널을 복제할 수 없었기 때문입니다.

그럼에도 Windows는 비판받을 여지가 있습니다. Linux는 Windows에 맞추기 위해 코드를 변경했지만, Windows는 수십 년 동안 수정되지 않았을 수도 있는 스크립트를 위해 1981년의 규칙을 계속 유지하고 있기 때문입니다.

Windows 11은 NUL.txt를 허용할 정도로 제한을 완화했지만, CON은 여전히 파일 이름이 아닌 장치로 취급됩니다. Windows 11에 여전히 포함되어 있는 Windows 95 힙 관리자처럼, 누군가의 30년 된 배치 파일을 손상시킬 가능성 때문에 MS가 제거할 수 없는 또 하나의 레거시 구성 요소입니다.

Windows Latest는 여러분과 같은 독자들의 지원에 의존합니다. Google Discover와 Google 검색에서 Windows Latest를 선호하는 소스로 설정해 독립적인 보도가 더 많은 사람에게 전달될 수 있도록 도와주세요.