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 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şkilendiriyorWindows 11’ CON, PRN, AUX NUL ifadeleri sıradan dosya adları olarak değerlendirilmek yerine sistemin özel aygıt adları arasında yer alıyor. İşletim sistemi, adları kullanan komutu normal 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 COM9 arasındaki adlar seri bağlantı noktalarıyla, LPT1 LPT9 arasındaki adlar ise paralel yazıcı bağlantılarıyla ilişkilendiriliyor. Microsoft’un dosya adlandırma belgeleri, adların dosya 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 kuralla bağlantılı.
Microsoft’un belgelerine göre.txt veya.tar.gz gibi uzantılı adlar NUL aygıt adıyla eşdeğer kabul edilmeli. Üst simge biçimindeki ¹, ² ³ rakamları 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 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ı devraldı. CP/M sisteminde aygıt isimleri genellikle CON: biçiminde iki nokta üst üste işaretiyle yazılıyordu; MS-DOS ise 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 karar olarak değerlendiriyor. Çünkü yalnızca CON yazıldığında sistemin dosyayı yoksa konsolu hedeflediğini ayırt etmek zorlaşıyordu. MS-DOS, aygıt adlarını özel kabul ederek belirsizliği çözdü; ancak söz konusu tercih sonraki Windows sürümlerine 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 dosya adlarını 8.3 biçimiyle sınırladığını açıklamıştı. dönemde kullanıcılar 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 1983 yılında alt dizin desteğinin eklenmesi, eski aygıt adlarının nasıl çalışacağı konusunda yeni karar gerektirdi. Microsoft, adların yalnızca kök dizinde değil, her klasörde özel anlamlarını korumasını tercih. Aksi durumda kullanıcıların 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 yazılımların 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 komutların bölümü gerçek dosyalara yazmaya başlayabilir uzun süredir kullanılan otomasyonlar beklenmedik sonuçlar üretebilir.
Geçmişte aynı kurallar güvenlik kararlılık sorunlarıyla ilişkilendirildi. Windows 95 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 yolun bazı durumlarda sistemin çökmesine neden olabildiğini kayda geçirmişti.
Windows 11 26H2 üzerinde gerçekleştirilen denemelerde CON, PRN, AUX, NUL COM1 gibi yalın adlar klasör adı olarak reddedildi. Buna karşılık.txt txt gibi uzantılı adlar Dosya Gezgini üzerinden kabul edildi. 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’ dosya yolları işlenirken önceki sürümlerden farklı ele alınabildiğini fark etmişti. Ancak dosya adının oluşturulabilmesi, işletim sisteminin onu sıradan dosya gibi sorunsuz yöneteceği anlamına gelmiyor. Microsoft Q&A topluluğunda ılan örnekte PowerShell,.txt dosyasını listeleyebilmesine rağmen dosyayı açamıyor veya silemiyordu.
Komut İstemi üzerinden yapılan yönlendirme denemeleri aygıt adlarının özel davranışını gösteriyor. echo hello > CON komutu, normal 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.c adlı 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ı eski uygulamalar davranışa güvenebildiğinden, yapılacak değişiklik geriye dönük uyumluluğu bozabilir. nedenle CON gibi adların Windows 11’ 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.
