Windows 11, CON Dosya Adını Neden Hâlâ Kabul Etmiyor? Yanıt MS-DOS’a Uzanan Bir Kurala Dayanıyor

Windows 11, onlarca yıllık dosya adlandırma kısıtlamasını koruduğu için kullanıcıların CON, PRN veya AUX gibi adlarla dosya ya da klasör oluşturmasına izin vermiyor. Microsoft mühendisi Raymond Chen’in açıkladığı üzere kuralın kökeni, henüz klasör desteği bulunmayan MS-DOS 1.0 dönemine kadar uzanıyor. Güncel Windows sürümlerinde bazı uzantılı adların kabul edilmesi ise Microsoft’un belgelerinde açıklanan davranışla işletim sisteminin gerçek davranışı arasında farklılık bulunduğunu gösteriyor.

Windows 11, Bazı Dosya Adlarını Donanım Aygıtlarıyla İlişkilendiriyor

Windows 11’de CON, PRN, AUX ve NUL ifadeleri sıradan dosya adları olarak değerlendirilmek yerine sistemin özel aygıt adları arasında yer alıyor. İşletim sistemi, bu adları kullanan bir komutu normal bir dosyaya yönlendirmek yerine ilgili aygıtla ilişkilendirebiliyor. Örneğin CON konsolu, PRN yazıcıyı, AUX yardımcı aygıtı, NUL ise çıktıyı atan sanal aygıtı temsil ediyor.

COM1 ile COM9 arasındaki adlar seri bağlantı noktalarıyla, LPT1 ile LPT9 arasındaki adlar ise paralel yazıcı bağlantılarıyla ilişkilendiriliyor. Microsoft’un dosya adlandırma belgeleri, bu adların dosya ve klasör isimlerinde kullanılmaması gerektiğini belirtiyor. Kısıtlama yalnızca Dosya Gezgini üzerinden oluşturulan dosyalarla sınırlı kalmıyor; Windows’un dosya yollarını yorumlama biçimi de bu kuralla bağlantılı.

Microsoft’un belgelerine göre NUL.txt veya NUL.tar.gz gibi uzantılı adlar da NUL aygıt adıyla eşdeğer kabul edilmeli. Üst simge biçimindeki ¹, ² ve ³ rakamları da COM¹ veya LPT³ gibi adların ayrılmış aygıt isimleri arasında değerlendirilmesine neden olabiliyor. Ancak güncel Windows 11 sürümünde yapılan denemeler, uzantı içeren bazı adların Dosya Gezgini üzerinden kabul edilebildiğini ortaya koyuyor.

Windows’un dosya adlandırma kuralları, Microsoft’un ilk işletim sistemi sürümlerinden çok daha eski bir uyumluluk tercihine dayanıyor. MS-DOS, kendisinden önce kullanılan CP/M işletim sistemiyle uyumlu çalışmayı hedeflerken aygıt adlandırma yaklaşımını da devraldı. CP/M sisteminde aygıt isimleri genellikle CON: biçiminde iki nokta üst üste işaretiyle yazılıyordu; MS-DOS ise bu işareti zorunlu olmaktan çıkardı.

OS/2 Museum’dan Michal Necasek, iki nokta üst üste işaretinin isteğe bağlı hale getirilmesini tasarım açısından sorunlu bir karar olarak değerlendiriyor. Çünkü yalnızca CON yazıldığında sistemin bir dosyayı mı yoksa konsolu mu hedeflediğini ayırt etmek zorlaşıyordu. MS-DOS, aygıt adlarını özel kabul ederek bu belirsizliği çözdü; ancak söz konusu tercih sonraki Windows sürümlerine de taşındı.

Microsoft mühendisi Raymond Chen, 2003 yılında yayımladığı Old New Thing blog yazısında MS-DOS 1.0’ın alt dizinleri desteklemediğini, küçük harf kullanımına izin vermediğini ve dosya adlarını 8.3 biçimiyle sınırladığını açıklamıştı. O dönemde kullanıcılar bir derleyicinin çıktısını yazıcıya göndermek için PRN adını, çıktıyı atmak için NUL adını, ekrana yönlendirmek için CON adını kullanabiliyordu.

MS-DOS 2.0 ile 1983 yılında alt dizin desteğinin eklenmesi, eski aygıt adlarının nasıl çalışacağı konusunda yeni bir karar gerektirdi. Microsoft, bu adların yalnızca kök dizinde değil, her klasörde özel anlamlarını korumasını tercih etti. Aksi durumda kullanıcıların bir klasöre geçtikten sonra NUL veya PRN gibi adlarla çıktı yönlendirmesi yapması tutarsız davranışlara yol açabilirdi.

Microsoft’un eski tasarım kararını sürdürmesinin temel nedenlerinden biri, mevcut betiklerin ve yazılımların bu davranışa bağımlı olması. Komut dosyaları, çıktıyı gizlemek için >NUL yönlendirmesini kullanabiliyor; eski yönergeler ise copy CON komutuyla dosya oluşturma yöntemini anlatabiliyor. Aygıt adlarının özel anlamı kaldırılırsa bu komutların bir bölümü gerçek dosyalara yazmaya başlayabilir ve uzun süredir kullanılan otomasyonlar beklenmedik sonuçlar üretebilir.

Geçmişte aynı kurallar güvenlik ve kararlılık sorunlarıyla da ilişkilendirildi. Windows 95 ve Windows 98, belirli aygıt adlarını içeren bazı yolları işlerken hata verebiliyordu. Microsoft’un Mart 2000 tarihli MS00-017 güvenlik bülteni, C:\con\con gibi bir yolun bazı durumlarda sistemin çökmesine neden olabildiğini kayda geçirmişti.

Windows 11 26H2 üzerinde gerçekleştirilen denemelerde CON, PRN, AUX, NUL ve COM1 gibi yalın adlar klasör adı olarak reddedildi. Buna karşılık CON.txt ve NUL.txt gibi uzantılı adlar Dosya Gezgini üzerinden kabul edildi. Bu davranış, Microsoft’un belgelerinde uzantılı adlar için tarif edilen kuralla çelişiyor.

Windows desteğini inceleyen Python geliştiricileri, 2022 yılında uzantı içeren aygıt adlarının Windows 11’de dosya yolları işlenirken önceki sürümlerden farklı ele alınabildiğini fark etmişti. Ancak bir dosya adının oluşturulabilmesi, işletim sisteminin onu sıradan bir dosya gibi sorunsuz yöneteceği anlamına gelmiyor. Microsoft Q&A topluluğunda paylaşılan bir örnekte PowerShell, NUL.txt dosyasını listeleyebilmesine rağmen dosyayı açamıyor veya silemiyordu.

Komut İstemi üzerinden yapılan yönlendirme denemeleri de aygıt adlarının özel davranışını gösteriyor. echo hello > CON komutu, normal bir dosya oluşturmak yerine metni konsola yazdırabiliyor. echo test > COM¹ komutu ise Microsoft’un belgelerinde tarif edilen aygıt adı kısıtlaması nedeniyle hata verebiliyor.

Windows’un eski dosya adlandırma kuralları yalnızca Microsoft ürünlerini geliştiren ekipleri etkilemiyor. Linux çekirdeği bakım ekipleri, 2024 yılında Windows üzerinde çekirdeği kopyalamayı engelleyen dosya adı sorununu aşmak amacıyla aux.c adlı bir grafik sürücüsü dosyasının adını auxch.c olarak değiştirdi. Değişiklik, Windows’un AUX adını özel aygıt adı olarak değerlendirmesinden kaynaklanan uyumluluk sorununa yönelikti.

Microsoft açısından eski kuralı kaldırmak, yalnızca dosya adlandırma davranışını değiştirmekten ibaret değil. Uzun süredir kullanılan komut dosyaları, yönetim araçları ve eski uygulamalar bu davranışa güvenebildiğinden, yapılacak bir değişiklik geriye dönük uyumluluğu bozabilir. Bu nedenle CON gibi adların Windows 11’de hâlâ reddedilmesi, işletim sistemlerinin geçmişten devraldığı tasarım kararlarının güncel yazılım ekosistemini nasıl şekillendirdiğini gösteriyor.