Windows’ta CON Adında Klasör Neden Oluşturulamıyor?

“Belirtilen aygıt adı geçerli değil.” Windows’un bu kısa uyarısı, aslında işletim sisteminin en eski kurallarından birinin sesidir. Bir klasöre CON adını verdiğinizde Windows bu üç harfi bir klasör adı olarak okumaz; onu klavyenizi ve ekranınızı kasteden kırk yıllık bir donanım kısayolu sanır. Windows’ta CON adında klasör neden oluşturulamıyor sorusunun cevabı da tam burada yatar: karşınızdaki şey bir yazılım hatası değil, 1981’de ilk IBM PC’nin işletim sistemi için verilmiş ve o günden beri bozulmadan taşınan bilinçli bir tasarım kararıdır.

Üstelik duvara çarptığınız tek ad CON değil. Bu içeriğimizde PRN, AUX, NUL, COM1–COM9 ve LPT1–LPT9 adlarının da neden yasaklı olduğunu, bu kuralın MS-DOS’tan nasıl miras kaldığını ve modern Windows’un onu neden kaldırmadığını sizler için inceledik. Bu adları taşıyan bir klasörü oluşturmanın bir yolu var mı, ona da değindik.

CON, PRN, AUX ve NUL Ne Anlama Geliyor?

Bu kelimeler aslında birer dosya adı değil, birer aygıt adıdır (device name). MS-DOS ve onun ardılı Windows, bilgisayara bağlı donanımı programlara “dosya” gibi sunar. Bir metni yazıcıya göndermek için ayrı bir yazıcı arayüzü çağırmanız gerekmez; çıktıyı PRN adlı “dosyaya” yazmanız yeterlidir. Aynı mantıkla NUL‘a yazdığınız her şey hiçbir yere gitmez, yani sessizce yok edilir.

Windows’ta rezerve edilmiş dosya adları listesi ve bu adların karşılık geldiği donanım şöyle:

Microsoft’un dosya, yol ve ad alanı adlandırma belgesi bu adları tek tek sayar. Listede ilginç bir ayrıntı da vardır: Windows, ISO/IEC 8859-1 üst simge rakamlarını da rakam kabul ettiği için COM¹, COM², COM³, LPT¹, LPT² ve LPT³ yazımları da rezervedir. Yani liste sandığınızdan biraz daha uzundur.

MS-DOS Aygıt Adlarının Windows’taki Mirası Nasıl Başladı?

Bu adların hikâyesi Microsoft’tan da eskidir. 1974’te Gary Kildall’ın geliştirdiği CP/M işletim sisteminde donanımlar CON:, LST:, PUN: ve RDR: gibi mantıksal adlarla çağrılıyordu. Tim Paterson’ın 1980’de yazdığı ve Microsoft’un 1981’de satın aldığı 86-DOS, CP/M ile uyumlu olacak şekilde tasarlandığı için bu alışkanlığı olduğu gibi devraldı.

DOS 1.0’da Aygıtlar Neden Dosya Adına Dönüştü?

Ağustos 1981’de IBM PC (5150) ile birlikte gelen PC DOS 1.0’da alt dizin diye bir kavram yoktu. Diskteki bütün dosyalar tek bir kök dizinde duruyordu. Programlar da kullanıcıdan bir çıktı dosyası adı istiyor, o adı diske yazıyordu.

İşletim sistemi burada zarif bir kestirme yol sundu: kullanıcı dosya adı olarak PRN yazarsa çıktı yazıcıya, NUL yazarsa hiçbir yere, CON yazarsa ekrana gidiyordu. Programın bu isimlerden haberi bile yoktu; işi DOS hallediyordu. Microsoft’un uzun yıllar Windows ekibinde çalışan geliştiricisi Raymond Chen, The Old New Thing’deki yazısında bu mekanizmayı tam olarak böyle anlatır. Dönemin klasik komutu copy con deneme.txt da aynı fikrin ürünüdür: klavyeden yazdıklarınızı doğrudan bir dosyaya kopyalar.

Aygıtı bir dosya gibi ele alma fikri size tanıdık geldiyse haklısınız; aynı yıllarda Unix dünyası da “her şey bir dosyadır” ilkesini işliyordu. Bu iki geleneğin farkını merak ediyorsanız Unix tasarım felsefesinin Linux’a bıraktığı mirası ele aldığımız yazımıza göz atabilirsiniz.

1983’te Klasörler Geldi, Aygıt Adları Kaldı

Asıl kritik karar 1983’te, IBM PC XT ile birlikte gelen DOS 2.0’da verildi. Bu sürüm sabit disk desteğiyle beraber ağaç yapılı dizinleri, yani bugün “klasör” dediğimiz şeyi getirdi. Peki kök dizinde çalışan NUL hilesi, alt dizine girildiğinde de çalışmalı mıydı?

Microsoft “evet” dedi. Aksi hâlde bir alt dizine geçen her kullanıcının ve her betiğin davranışı bozulacaktı. Böylece aygıt adları her dizinde geçerli sanal dosyalar hâline geldi. C:\Belgeler\NUL da, D:\proje\alt\CON da aygıta gider. Bu kararın bedeli ise şudur: aynı adı gerçek bir klasör için kullanmak artık mümkün değildir.

Aynı dönemin bir başka kalıcı mirası da 8 karakter ad + 3 karakter uzantı kuralıdır; onun hikâyesini dosya uzantılarının neden 3 harfli olduğunu anlattığımız içeriğimizde bulabilirsiniz. Bu davranışı bugün kendi gözünüzle görmek isterseniz DOSBox emülatörünü kurup copy con komutunu denemeniz yeterli.

Modern Windows’ta CON Adında Klasör Neden Oluşturulamıyor?

Bugünkü Windows’un dosya sistemi NTFS ve NTFS’in “CON” adında bir klasörle hiçbir sorunu yok. Kısıtlama disk üzerinde değil, Win32 API katmanında, yani uygulamaların dosya açarken geçtiği yol ayrıştırma aşamasında duruyor. Sebep tek kelimeyle geriye dönük uyumluluktur.

Bu kuralı ayakta tutan pratik gerekçeler şöyle sıralanabilir:

• Onlarca yıllık toplu iş dosyaları (batch) çıktıyı susturmak için hâlâ > NUL yazıyor.
• Eski betikler bir dizinin var olup olmadığını if exist klasor\nul hilesiyle sınıyor.
• Sanayi ve laboratuvar yazılımları seri porta COM1 adıyla erişmeye devam ediyor.
• Kurumsal ortamlarda hâlâ çalışan on binlerce eski uygulama bu davranışı varsayıyor.

Windows NT ile birlikte bu adlar çekirdek düzeyinde daha düzenli bir yapıya kavuştu. Microsoft’un sürücü belgelerine göre COM1 aslında nesne yöneticisi içinde \DosDevices\COM1 adlı bir sembolik bağdır ve \Device\Serial0 gibi gerçek bir aygıt nesnesini gösterir. Sysinternals’ın WinObj aracıyla bu ad alanını kendi gözünüzle gezebilirsiniz.

Bu yapının somut bir sonucu da şudur: yalnızca COM1–COM9 arası adların hazır kısayolu vardır. 100 portlu bir seri kart taktıysanız COM56 adını doğrudan açamazsınız; Microsoft’un belgelediği gibi \\.\COM56 yazarak aygıt ad alanına doğrudan gitmeniz gerekir.

Rezerve Adlar Bugün Hangi Sorunlara Yol Açıyor?

Bu kırk yıllık miras zaman zaman ciddi baş ağrıları çıkardı. En ünlü örneği Microsoft’un 16 Mart 2000’de yayımladığı MS00-017 güvenlik bültenidir. Windows tek bir aygıt adını doğru şekilde reddediyordu; ancak C:\CON\CON gibi birden fazla aygıt adı içeren yolları denetlemiyordu. Bu yolu açmaya çalışmak Windows 95, 98 ve 98 SE makinelerini çökertiyordu. Kötü niyetli bir web sayfası, sadece böyle bir bağlantı vererek ziyaretçinin bilgisayarını mavi ekrana düşürebiliyordu.

Bugünkü etkisi ise daha çok yazılım geliştiricileri ilgilendiriyor. Linux veya macOS’te aux.h ya da src/aux/ gibi bir dosya oluşturmak tamamen serbesttir. Aynı depoyu Windows’ta klonlamaya çalıştığınızda Git “invalid path” hatası verir ve çalışma kopyasını tamamlayamaz. Bu yüzden çok platformlu projelerde rezerve adlardan kaçınmak bir görgü kuralı hâline gelmiştir.

Windows 11 Rezerve Dosya Adı Kısıtlamasında Neyi Değiştirdi?

Uzun yıllar boyunca kural katıydı: Windows, adın uzantısını atıp geriye kalanı aygıt listesiyle karşılaştırdığı için CON.txt da NUL.mp3 da aygıta yönleniyordu. Uzantı eklemek işe yaramıyordu.

Windows 11 ile bu ayrıştırma sadeleştirildi. Microsoft’un .NET yol biçimleri belgesinde açıkça belirtildiği gibi, Windows 11 öncesinde eski bir aygıt adıyla başlayan yol her zaman aygıt olarak yorumlanırdı ve bu artık geçerli değildir. Yani CON.TXT otomatik olarak \\.\CON hâline gelmez; aygıta erişmek isteyen geliştiricinin tam yolu yazması beklenir. Karşılaştırma öncesinde harfler büyütülür, sondaki nokta ve boşluklar atılır; bu yüzden com1.. hâlâ aygıta denk gelir.

Ama işin özü değişmedi: çıplak CON, PRN, AUX, NUL, COM1 ve LPT1 adları hâlâ rezerve. Üstelik NUL, yolun son bileşeni olduğunda ayrıca özel muamele görmeye devam ediyor. Dosya Gezgini de kendi kontrollerini sürdürdüğü için pratikte karşınıza yine aynı hata çıkar. Kısacası 2026 itibarıyla bu kuralın kalkması beklenmiyor.

CON Adında Klasör Nasıl Oluşturulur?

Yasak dosya sisteminde değil, yol ayrıştırmasında olduğu için bu katmanı atlatmak mümkündür. Windows’un \\?\ ve \\.\ önekleri, yolu normalleştirmeden doğrudan dosya sistemine iletir. Komut istemini yönetici olarak açıp şu komutu çalıştırdığınızda C sürücüsünde gerçekten con adlı bir klasör oluşur:

• Oluşturmak için: mkdir \\?\C:\con
• Silmek için: rmdir \\?\C:\con

Bir uyarı borçluyuz: bu klasör “normal” araçlar için görünmez bir mayın tarlasıdır. Dosya Gezgini onu açmakta zorlanır, birçok yedekleme ve antivirüs yazılımı içindekilere erişemez, hatta klasörü aynı önek olmadan silemezsiniz. Merak gidermek için denemesi eğlenceli, ama içine gerçek veri koymak kesinlikle önerilmez.

Sonuç

CON adında bir klasör açamamanız, Windows’un beceriksizliğinden değil, kırk yılı aşkın bir uyumluluk sözünden kaynaklanıyor. 1981’de tek dizinli bir disket dünyasında pratik bir kolaylık olarak doğan aygıt adları, 1983’te dizinler geldiğinde de korundu ve o günden bu yana milyonlarca satır kodun varsaydığı bir davranışa dönüştü. Windows 11 kuralın kenarlarını yontsa da özünü kaldırmadı; çünkü kaldırmanın maliyeti, getireceği rahatlıktan çok daha büyük.

Eğer bu tarz teknoloji tarihi içerikleri hoşunuza gidiyorsa, sitemizde yer alan “Steve Jobs Xerox PARC Ziyareti: Çalıntı Fikir Efsanesi” adlı yazımıza da göz atabilirsiniz.