Windows 11 umožňuje souborům mít názvy dlouhé 200 znaků plné mezer a emotikonů, Průzkumník souborů však odmítne pojmenovat soubor nebo složku CON. CON, PRN, AUX, NUL, COM1 až COM9 a LPT1 až LPT9 jsou vyhrazené názvy zařízení. Inženýr MSu Raymond Chen vystopoval jejich původ až k systému DOS 1.0, který dokonce ani nepodporoval složky.

Pravidlo jsem otestoval na počítači se systémem Windows 11 26H2. Omezení zavedené operačním systémem z roku 1981 stále pevně platí, ačkoli Windows Latest zjistil, že jeho část již nefunguje tak, jak popisuje dokumentace MSu.

CON, PRN, AUX a NUL jsou ve Windows 11 zařízení, nikoli názvy souborů

Každý vyhrazený název odpovídá určitému zařízení. Zvláště pozoruhodný je NUL: funguje jako černá díra, která zahodí vše, co je do ní odesláno.

Dokumentace MSu k pojmenovávání souborů stále vývojářům nařizuje: “Nepoužívejte následující vyhrazené názvy jako názvy souborů.” Omezení se vztahují také na složky, protože Windows považuje složku za zvláštní typ souboru.

Podle MSu by přidání přípony nemělo toto omezení obejít, ačkoli v některých případech se tak děje. Společnost uvádí: “NUL.txt a NUL.tar.gz jsou oba ekvivalentní názvu NUL.” Výjimku nemají ani číslice v horním indexu. Windows interpretuje ¹, ² a ³ jako číslice, takže názvy jako COM¹ a LPT³ jsou vyhrazené “v každém adresáři.”

Z hlediska architektury je COM1 odkazem na sériový port uvnitř jádra Windows. MS jej označuje jako název zařízení systému MS-DOS, takže zadáním COM1 se přistupuje k portu, nikoli k souboru.

Raymond Chen vysvětluje, proč pravidlo z DOSu 1.0 stále platí ve Windows 11

Příběh začíná u CP/M, operačního systému, s nímž se MS-DOS snažil zachovat kompatibilitu. V systému CP/M názvy zařízení vždy obsahovaly dvojtečku, například CON:. MS-DOS učinil dvojtečku volitelnou, což Michal Necasek z muzea OS/2 označuje za “osudovou chybu.” Prostý název jako CON neposkytuje DOSu žádnou informaci o tom, zda odkazuje na soubor, nebo na konzoli.

V příspěvku z roku 2003 na svém blogu Old New Thing Chen vysvětlil, že “DOS 1.0 nepodporoval podadresáře, malá písmena ani názvy souborů delší než ve formátu 8.3.” Toto omezení je také neobvyklým důvodem, proč si některé z nejstarších systémových souborů Windows 11 zachovávají názvy z éry DOSu.

Pokud se tehdy assembler zeptal, kam má uložit výstup, a uživatel jej chtěl vytisknout, “zadali jste jako název souboru ‘PRN’.” Zadání NUL výstup zahodilo, zatímco CON jej zobrazilo na obrazovce.

Protože disky měly pouze jeden adresář, neexistovalo žádné jiné místo, kde by tyto speciální názvy mohly fungovat. Když v roce 1983 s DOSem 2.0 přišly složky, musely názvy zařízení fungovat také uvnitř nich. Jak Chen vysvětlil, jinak by uživatelé nemohli přejít do jiné složky, spustit assembler a zadáním NUL zahodit jeho výstup. MS proto zajistil, aby tyto názvy fungovaly v každé složce, a právě proto ani dnes nelze ve složce Dokumenty vytvořit soubor s názvem PRN.

Proč MS toto chování ani po více než 40 letech neodstranil? “Protože na ně stále všichni spoléhají,” napsal Chen. Dávkové soubory potlačují výstup jeho přesměrováním do >NUL, skripty kontrolují existenci složky pomocí “if exist directoryname\nul,” a starší příručky uživatelům radí vytvářet soubory příkazem “copy CON.”

Pokud by bylo toto pravidlo odstraněno, každý skript přesměrovávající výstup do NUL by místo toho začal zapisovat skutečné soubory.

Toto pravidlo kdysi způsobovalo pády celých počítačů. Windows 95 a Windows 98 odmítaly cesty obsahující jeden název zařízení, ale selhaly, pokud cesta obsahovala dva, například C:\con\con. Bezpečnostní bulletin MSu MS00-017 z března 2000 připustil, že to “obvykle vede k pádu systému.”

Pravidlo z éry DOSu jsem otestoval ve Windows 11 26H2 a NUL.txt prošel

Na počítači se systémem Windows 11 26H2 se při přejmenování nové složky na CON zobrazila zpráva “Zadaný název zařízení je neplatný.” Odmítnuty byly také názvy PRN, AUX, NUL a COM1.

Název NUL.txt však byl přijat bez chyby, stejně jako CON.txt, přestože dokumentace MSu stále uvádí, že NUL.txt je ekvivalentní názvu NUL.

Ačkoli dokumentace MSu nebyla aktualizována, vývojáři zkoumající podporu Windows v Pythonu v roce 2022 zjistili, že Windows 11 přestal při zpracování cest k souborům považovat názvy zařízení s příponami za speciální.

Takové soubory se bohužel mohou chovat nepředvídatelně. Jeden uživatel služby MS Q&A zjistil, že PowerShell dokáže soubor NUL.txt zobrazit v seznamu, ale nedokáže jej otevřít ani odstranit. Komunitní poradce odpověděl, že “výsledek může být nepředvídatelný.” To může vysvětlovat, proč MS nadále uvádí, že přípony nemají na názvy jako NUL.txt a CON.txt žádný vliv.

Příkazový řádek stále dokáže předvést původní chování DOSu. Spuštění příkazu echo hello > CON vypsalo “hello” na obrazovku namísto vytvoření souboru, zatímco příkaz echo test > COM¹ selhal přesně tak, jak popisuje dokumentace MSu.

Než začneme Windows kritizovat, stojí za zmínku, že správci Linuxu v roce 2024 přejmenovali soubor grafického ovladače z aux.c na auxch.c, protože původní název bránil uživatelům v klonování linuxového jádra ve Windows.

Windows však stále lze kritizovat, protože Linux upravil svůj kód tak, aby se přizpůsobil Windows, zatímco Windows nadále zachovává pravidlo z roku 1981 kvůli skriptům, kterých se možná nikdo nedotkl celá desetiletí.

Windows 11 omezení zmírnil natolik, že umožňuje název NUL.txt, ale CON je stále považován za zařízení, nikoli za název souboru. Stejně jako správce haldy z Windows 95, který je stále součástí Windows 11, jde o další zastaralou komponentu, již MS nemůže odstranit, aniž by potenciálně poškodil něčí 30 let starý dávkový soubor.

Windows Latest je závislý na čtenářích, jako jste vy. Nastavte si nás jako preferovaný zdroj ve službách Google Discover a Vyhledávání Google a pomozte našemu nezávislému zpravodajství oslovit více lidí.