Aynı klasörde iki ayrı ad
CREATE_NEW ile oluşturulan iki dosya aynı klasörde duruyor.
- İki dosya adı
Testin anlatımlı videosuacilis4.mkv, kaynak kare 0:12
Windows için i'nin büyüğü hangi harf?
Bu NTFS biriminde izmir.txt ve İZMİR.txt iki ayrı dosya olarak oluştu, Türkçe dil kıyası ise aynı adları eşit saydı.
CSINT-NEWS-2026-012Arşivde aç
Belgeler
Sarı vurgular sonradan eklendi, özgün görüntü değişmedi.
Bütün belgeler için. CSINT'in özgün terminal kaydından kırpıldı. Yazı yeniden üretilmedi; vurgular ayrı katmanda. Bütün belgelerin tarihi 18 Ekim 2026.
Türkçe kıyas eşit diyor
Aynı iki ad için dil kıyası 2, yani eşit döndü.
- tr-TR sonucu 2, eşit
Göstermediği. Seçilen seçenekler onuncu belgede. Seçeneksiz kıyas ölçülmedi.
Testin anlatımlı videosuacilis4.mkv, kaynak kare 0:32
İlk üç çiftte bir, son üç çiftte iki dosya
Aynı ad kararı verilen çiftte yalnızca ilk dosya kaldı.
- Birer dosya
- İkişer dosya
Testin anlatımlı videosuolcum.mkv, kaynak kare 1:01
Okunan tablo ve eşleşen CRC64
Okuyucu tabloyu diskten aldı ve CRC64 eşleşmesini bildirdi.
- 131072 bayt tablo
- CRC64 aynı
Göstermediği. $Info sürüm alanlarının anlamı ntfs-3g'ye dayanıyor. Bunlardan güncelleme geçmişi çıkarılmadı.
Testin anlatımlı videosutablo.mkv, kaynak kare 0:14
I için iki giriş, İ ve ı için yalnız kendileri
Bu dört karakter için yalnız seçilmiş hücreler değil, tablonun tamamındaki eşler sayıldı.
- I ve i aynı değeri veriyor
- İ ve ı yalnız kendileri
Testin anlatımlı videosutablo.mkv, kaynak kare 0:39
Değişen ayarlar kayıtta
Kullanıcı biçimi ve sistem yerel ayarı değişti.
- A koşulu
- B koşulu
- C koşulu
Testin anlatımlı videosuyerel.mkv, kaynak kare 0:16
Üç koşul, 36 aynı karar
İki oluşturma sırası dahil, altı çiftin kararı üç koşulda aynı kaldı.
- A, B ve C'de altışar karar
Testin anlatımlı videosuyerel.mkv, kaynak kare 0:26
C koşulunda tablo değişmedi
Sistem yerel ayarı Türkçe olduktan sonra okunan iki akış da başlangıç kopyalarıyla bayt bayt aynı.
- CRC64 eşleşiyor
- Tablo ve $Info aynı
Testin anlatımlı videosuyerel.mkv, kaynak kare 0:35
Ayarlar en-US'a döndü
Deneyden sonra alınan kayıt başlangıçtaki kullanıcı ve sistem yerel ayarlarını doğruluyor.
- Geri yüklenen değerler
Testin anlatımlı videosuyerel.mkv, kaynak kare 0:46
Dil kıyası açık seçeneklerle yapıldı
tr-TR sonucunun hangi seçeneklerle alındığı betikte görünüyor.
- İki seçenek
- Çağrıdaki değer
Testin anlatımlı videosukiyas.mkv, kaynak kare 0:14
Kısa sonuç
Üç koşuldaki 36 dosya oluşturma kararı aynı çıktı. İlk üç çift aynı ad sayıldı, son üç çiftte iki ayrı dosya oluştu. Diskin tablosu bu kararların tamamını öngördü; Türkçe dil kıyası üçüncü, dördüncü ve beşinci çiftte dosya sisteminden farklı sonuç verdi.
Sınır
Tek bilgisayarın C sürücüsündeki NTFS birimi ölçüldü. NTFS'in iç çağrıları izlenmedi. Explorer, başka birimler, menü dili değişikliği ve ANSI programları denenmedi.
Ayrıntılı anlatım ve kaynak dökümüYöntem, zaman çizelgesi ve tam metin. Bulgular yukarıdaki belgelerde.
İncelenen iddia
Dosya adının eşitliği ile Türkçe dil kurallarına göre eşitlik, aynı Windows üzerinde aynı sonucu vermek zorunda değil.
Ölçümün sınırı
- Aynı altı çift, iki oluşturma sırası ve üç yerel ayar koşulu ölçüldü. Sonuç 36 kararda da aynı.
- Klasörlerin büyük/küçük harf duyarlılığı kapalıydı. Kullanıcı biçimi ve Unicode dışı programların sistem yerel ayarı değişti; menü dili en-US kaldı.
- Tablodan hesaplanan sonucun ölçümle uyuşması, NTFS'in o anda yaptığı iç çağrıların izlendiği anlamına gelmiyor.
- CompareStringEx için tr-TR ile LINGUISTIC_IGNORECASE ve NORM_LINGUISTIC_CASING seçildi. Bu seçenekler olmadan aynı kıyas ölçülmedi.
Aynı ad ne demek?
Türkçede küçük i'nin büyüğü noktalı İ, küçük ı'nın büyüğü noktasız I. Windows'a iki dosya adı verdiğimde, bu dil kuralını kullanıp kullanmayacağını görmek istedim.
İlk karşıtlık izmir.txt ile İZMİR.txt oldu. Dosya sistemi bunları aynı klasörde ayrı dosya olarak oluşturdu. tr-TR ile yapılan dil kıyası ise eşit dedi. izmir ile IZMIR çiftinde bunun tersi görüldü.
Dosyalar nasıl oluşturuldu?
Her çift için boş bir klasör kullanıldı. Betik Unicode adları CreateFileW çağrısına verdi ve CREATE_NEW ile oluşturdu. Ad zaten varsa çağrı başarısız olur; mevcut dosya açılıp üzerine yazılmaz. İkinci dosya için hata 80, aynı ad kararını gösterdi.
Çiftler AB ve BA sırasıyla denendi. Her denemede dosya kimlikleri, klasördeki dosya sayısı ve ilk dosyanın içeriği kontrol edildi. Birimin büyük/küçük harfe duyarlı aramayı desteklemesi ile klasörün bu özelliği açık kullanması ayrı kaydedildi. Test klasörlerinin özelliği kapalıydı.
İlk betikte karakter aktarımı ve dosya kimliği yapısının hizalaması düzeltildi. Ardından temiz klasörlerde yeniden ölçüm alındı. A, B ve C koşulları aynı ölçüm betiğiyle çalıştırıldı.
- elma / ELMA, aynı ad. ASCII kontrolü.
- çorba / ÇORBA, aynı ad. Ç harfi için kontrol.
- izmir / IZMIR, aynı ad.
- izmir / İZMİR, iki ayrı dosya.
- ılık / ILIK, iki ayrı dosya.
- ılık / İLİK, iki ayrı dosya.
Diskteki tablo ne dedi?
MS-FSCC, $UpCase dosyasını sıralamada kullanılan büyük harf tablosu olarak tanımlıyor. Belge bu diskin tablosunun içeriğini vermiyor. İçeriği diskin kendisinden okudum.
Okuyucu ham birimi yalnızca GENERIC_READ hakkıyla açtı ve 131.072 baytlık tabloyu okudu. Salt okunur olan bu erişimdi; çıktı dosyaları aynı C sürücüsüne kaydedildi. Hesaplanan CRC64, $Info akışında okunan DADC7E776B1B690C ile eşleşti.
Tabloda U+0069 olan i, U+0049 olan I'ya gidiyor. U+0130 olan İ ve U+0131 olan ı kendi değerlerinde kalıyor. Tablonun tamamında I değerini yalnız I ve i veriyor; İ ve ı için başka eş yok.
Her adın UTF-16 kod birimini bu tabloyla dönüştürüp kıyasladım. Altı çiftin tamamı dosya oluşturma ölçümüyle uyuştu. Bu uyum, dosya sisteminin iç çalışmasının izlenmesiyle aynı kanıt değil.
$Info alanlarının adlandırılması okuyucu koduna ve ntfs-3g'ye dayanıyor. Buradaki 10.0 ve 26100 değerlerinden tablonun ne zaman veya hangi güncellemede yazıldığı sonucu çıkarılmadı.
Türkçe yerel ayar sonucu değiştirdi mi?
A koşulunda kullanıcı biçimi ve sistem yerel ayarı en-US idi. B'de yalnız kullanıcı biçimi tr-TR yapıldı. C'de sistemin Unicode dışı programlar için kullandığı yerel ayar da tr-TR oldu. C için yeniden başlatma yapıldı.
B'de ANSI/OEM kod sayfaları 1252/437 kaldı; C'de 1254/857 oldu. Get-UICulture üç koşulda da en-US verdi. Bu yüzden sonuç menü dilinin değişmesi hakkında bir ölçüm değil.
Her koşulda 12 karar alındı. Üçünde de ilk üç çiftin ikinci oluşturması aynı ada çarptı, son üç çiftte iki dosya oluştu. C'de tekrar okunan $UpCase ve $Info, başlangıç kopyalarıyla bayt bayt aynıydı.
Sonunda kullanıcı ve sistem yerel ayarları en-US'a döndürüldü. Yeniden başlatma sonrası alınan kayıtta kullanıcı ve sistem dili en-US, LCID 0x0409, ACP 1252 ve OEMCP 437 olarak doğrulandı.
Diğer kıyas neden farklı?
Dosya oluşturmayan iki karşılaştırma da kaydedildi. CompareStringOrdinal büyük/küçük harfi yok sayarak çalıştı. CompareStringEx ise tr-TR ve en-US adlarıyla, 0x08000010 değeriyle çalıştı. Bu değer LINGUISTIC_IGNORECASE ile NORM_LINGUISTIC_CASING seçeneklerini birleştiriyor.
Microsoft, NORM_LINGUISTIC_CASING seçeneğinin dosya sistemi kuralları yerine dilin harf kurallarını kullandığını söylüyor. Ölçülen fark, seçilen kıyas yöntemleri arasında. Windows'un her yerde tek bir dil kuralı kullandığı sonucu çıkarılamaz.
Türkçe kıyas izmir / İZMİR ve ılık / ILIK çiftlerini eşit, izmir / IZMIR çiftini eşit değil saydı. İngilizce kıyas ve ordinal kıyas, denenen altı çiftte NTFS kararıyla uyuştu. Bu fonksiyon sonuçları dosya oluşturmadan hesaplandı.
Bu testten ne çıkar?
Bu birimde dosya adı eşitliğini Türkçe kelime eşitliğiyle aynı kabul etmek doğru çıkmadı. Bir uygulama dosya adlarını dil kıyasıyla tekilleştiriyorsa, uygulamanın aynı saydığı adlarla dosya sisteminin aynı saydığı adlar ayrışabilir. Böyle bir uygulamada bunun gerçek bir hataya yol açıp açmadığı ayrıca ölçülmeli.
Testin ham kayıtları yerelde korundu. Sayfanın belge kareleri bu kayıtlardan kırpıldı; yazı yeniden üretilmedi. Sayıların, koşulların, tablonun özet değerlerinin ve geri yükleme kaydının sadeleştirilmiş JSON dökümü kaynaklar arasında. Bu dosya ham log veya NTFS çağrı izi diye sunulmuyor.