Попробуйте прямо сейчас: создайте на рабочем столе новую папку и назовите ее CON. Windows выдаст ошибку о недопустимом имени устройства и вернет стандартное «Новая папка». То же самое произойдет с PRN, AUX, NUL, COM1 или LPT1.
Два с лишним десятка обычных на вид слов запрещены для использования в качестве имен файлов и папок. Каждое из них — старый адрес, который когда-то указывал на конкретное устройство. Windows хранит верность этому наследию уже более 40 лет.
Два десятка запретных слов
В официальной документации Microsoft приводится список зарезервированных имен, который включает CON, PRN, AUX, NUL, а также COM1–COM9 и LPT1–LPT9. Итого 22 названия, которые недоступны для обычных файлов и папок. Кроме того, система резервирует еще шесть вариантов с надстрочными индексами, например COM¹ и LPT³.
Каждый из этих идентификаторов когда-то указывал на физическое или логическое устройство. CON — это консоль, через которую осуществлялся ввод с клавиатуры и вывод на экран. PRN обозначал принтер, установленный по умолчанию. AUX — вспомогательное последовательное устройство. NUL — «цифровая мусорка», которая принимала любые данные и бесследно их уничтожала. Имена COM относились к последовательным портам, а LPT — к параллельным портам принтеров.
Истоки этого ограничения уходят во времена, когда файлы и устройства были равноправны с точки зрения операционной системы.
DOS приравнял устройства к файлам
Когда DOS 1.0 появилась вместе с IBM PC в августе 1981 года, она использовала раннюю версию файловой системы FAT, которую Windows поддерживает до сих пор. Однако ключевая особенность заключалась в том, что в DOS не существовало каталогов. Каждый диск содержал лишь плоский список файлов без какой-либо иерархии.
Операционной системе требовался универсальный способ для программного взаимодействия с оборудованием — принтерами, портами и консолью. У CP/M — предшественницы DOS, оказавшей на нее огромное влияние, — уже имелось элегантное решение. Система позволяла обращаться к устройствам по именам, которые программы могли открывать и использовать точно так же, как обычные файлы.
В DOS это работало следующим образом: при открытии PRN и записи данных байты отправлялись напрямую на принтер. Чтение из CON возвращало ввод с клавиатуры, а запись в CON выводила информацию на экран. Таким образом, программы взаимодействовали с оборудованием через те же операции, что и с обычными файлами.
Данный подход напоминал модель устройств Unix, где специальные файлы хранились в каталоге /dev. Однако DOS избрала иной путь, имена устройств работали в любом контексте. Именно поэтому в современных пакетных скриптах Windows до сих пор можно встретить конструкцию > NUL, которая отправляет вывод в «никуда».
Проблема возникла с самого начала, DOS не выделила имена устройств в отдельную зону. Unix размещал файлы устройств в /dev, а DOS распознавала свои имена устройств везде, где только могло появиться имя файла.
Папки пришли, а имена остались
В марте 1983 года DOS 2.0 принесла поддержку иерархических каталогов. Пользователи наконец-то получили возможность организовывать файлы по папкам, а не хранить всё в одном огромном списке. Однако это усовершенствование породило проблему обратной совместимости.
Существующие программы уже привыкли, что такие имена, как PRN, работают вне зависимости от текущего местоположения. Изменить это поведение после введения папок означало бы сломать множество приложений, написанных для ранних версий DOS.
Microsoft поступила прагматично, механизм разбора путей был настроен так, чтобы зарезервированные имена распознавались в любом каталоге. Вместо того чтобы поместить их в специальное системное место (по аналогии с Unix и /dev), DOS сделала их глобальными. В результате путь типа C:\Users\Documents\PRN интерпретируется не как файл в папке «Документы», а как устройство-принтер.
Как только имя оказывается доступным повсеместно, оно автоматически становится недоступным для обычных файлов где бы то ни было.
Расширение не спасает
Одно из самых коварных свойств этой системы — расширение файла не играет никакой роли. Windows проверяет базовое имя на соответствие списку системных устройств до того, как обрабатывает расширение. Поэтому CON.txt по-прежнему интерпретируется как консоль, NUL.mp3 — как null-устройство, а AUX.c — как вспомогательное устройство.
Эта особенность регулярно создает головную боль разработчикам, работающим с разными операционными системами. На Linux и macOS можно без проблем создавать файлы с именами aux.c или nul.h, поскольку там имена устройств изолированы в каталоге /dev. Но при попытке клонировать такой репозиторий на Windows возникает проблема: Win32 API отклоняет запрещенное имя, и Git не может создать файл на диске. Операция клонирования или обновления рабочей копии завершается ошибкой. Никакие настройки не помогут, проблему можно решить только переименованием файла непосредственно в репозитории.
Парадокс NTFS: создать можно, удалить сложно
Вот где кроется главный сюрприз: файловая система NTFS вполне способна хранить файл или папку с именем CON. Ограничение находится уровнем выше — в слое обработки путей Win32, который преобразует имена, переданные приложениями, во внутреннее пространство имён Windows.
Если обойти стандартную нормализацию путей, ограничение исчезает. Из командной строки можно выполнить:
mkdir \\?\C:\Users\Имя\Desktop\con
Префикс \\?\ отключает обычную обработку Win32 и передает путь напрямую файловой системе. Папка успешно создается и появляется на рабочем столе.
Однако удалить ее через Проводник не получится, интерфейс по-прежнему использует стандартную обработку Win32 и упирается в тот же конфликт с зарезервированным именем. Остается только командная строка:
rmdir \\?\C:\Users\Имя\Desktop\con
Этот контраст точно демонстрирует природу ограничения. NTFS имя хранит, а стандартный слой Windows отказывается его обрабатывать.
CON\CON: когда наследие превращалось в оружие
Зарезервированные имена устройств доставляли неприятности, далеко выходящие за рамки неудобств с именами папок. Ошибка CON/CON остается одним из самых известных багов в истории Windows.
На Windows 95, 98 и Windows 98 Second Edition обращение к устройству через некорректный вложенный путь вроде C:\CON\CON или C:\AUX\AUX могло привести к зависанию или полному краху системы.
Проблема стала по-настоящему серьезной, когда выяснилось, что веб-страницы и HTML-письма способны активировать этот баг. Злоумышленник мог разместить ссылку на локальный файл с таким путем — и когда браузер или почтовый клиент пытались загрузить ресурс, система падала.
Microsoft устранила уязвимость 16 марта 2000 года, выпустив Security Bulletin MS00-017. Патч добавил проверку путей с несколькими именами DOS-устройств. Однако саму систему зарезервированных имен не тронули — слишком много программного обеспечения уже полагалось на это поведение.
Почему Microsoft не убирает список до сих пор
За десятилетия, прошедшие с момента появления DOS, в Windows накопилось огромное количество скриптов и приложений, которые так или иначе обращаются к NUL, CON, COM1 и LPT1. Windows продолжает поддерживать эти псевдонимы, поскольку их удаление может нарушить работу программ, ожидающих старого поведения.
Цена сохранения этой системы минимальна — она проявляется лишь в невозможности использовать два десятка слов как имена файлов. А цена удаления может оказаться неприемлемо высокой, если какая-то критическая утилита или бизнес-скрипт перестанет функционировать.
Так они и остаются — 22 зарезервированных слова в каждом каталоге вашего диска. Все еще ждут принтера, которого уже давно нет.