Two distinct names in one directory
Both files created with CREATE_NEW exist in one directory.
- Both filenames
Frame from the original test recordingacilis4.mkv, source frame 0:12
Which uppercase I does Windows use?
On this NTFS volume, izmir.txt and İZMİR.txt were created as distinct files, while a Turkish linguistic comparison treated them as equal.
CSINT-NEWS-2026-012Open in archive
Documents
The yellow highlights were added later. The original image is unchanged.
For every document. Cropped from CSINT's original terminal recording. Text was not reconstructed; highlights are separate. All documents are dated 18 October 2026.
The Turkish comparison says equal
The linguistic comparison returned 2, equal, for the same two names.
- tr-TR returns 2, equal
What it does not show. The selected flags are shown in document ten. The comparison without them was not tested.
Frame from the original test recordingacilis4.mkv, source frame 0:32
One file for the first three pairs, two for the last three
Only the first file remains for a colliding pair.
- One file each
- Two files each
Frame from the original test recordingolcum.mkv, source frame 1:01
The table read and its matching CRC64
The reader obtained the table from the volume and reported matching CRC64.
- 131072-byte table
- Matching CRC64
What it does not show. $Info version-field interpretation follows ntfs-3g. No update history was inferred from these values.
Frame from the original test recordingtablo.mkv, source frame 0:14
Two preimages for I; only themselves for İ and ı
For these four characters, preimages were counted across the complete table, not just selected cells.
- I and i produce the same value
- İ and ı only map to themselves
Frame from the original test recordingtablo.mkv, source frame 0:39
The changed settings are recorded
User format and system locale changed.
- Condition A
- Condition B
- Condition C
Frame from the original test recordingyerel.mkv, source frame 0:16
Three conditions, 36 unchanged decisions
Including both creation orders, decisions for all six pairs stayed unchanged across the three conditions.
- Six of each decision in A, B and C
Frame from the original test recordingyerel.mkv, source frame 0:26
The table did not change in condition C
Both streams read after changing the system locale to Turkish are byte-identical to the baseline copies.
- CRC64 matches
- Table and $Info are identical
Frame from the original test recordingyerel.mkv, source frame 0:35
Settings restored to en-US
The post-experiment record confirms the original user and system locales.
- Restored values
Frame from the original test recordingyerel.mkv, source frame 0:46
The linguistic comparison used explicit flags
The script shows the options used for the tr-TR result.
- Both flags
- Value passed to the call
Frame from the original test recordingkiyas.mkv, source frame 0:14
Bottom line
All 36 file-creation decisions matched across the three conditions. The first three pairs collided and the last three produced distinct files. The disk table predicted every decision; Turkish linguistic comparison disagreed with the filesystem on pairs three, four and five.
Limits
One computer's NTFS C drive was tested. NTFS internals were not traced. Explorer, other volumes, display-language changes and ANSI applications were not tested.
Full account and source transcriptMethod, timeline and full text. The findings are in the documents above.
The claim reviewed
Filename equality and equality under Turkish linguistic rules need not give the same answer on the same Windows system.
Limits of the measurement
- The same six pairs, both creation orders and three locale conditions produced 36 unchanged decisions.
- Directory case sensitivity was disabled. User format and the system locale for non-Unicode applications changed; display language stayed en-US.
- Agreement between the disk-table calculation and file creation is not a trace of the filesystem's internal calls.
- CompareStringEx used tr-TR with LINGUISTIC_IGNORECASE and NORM_LINGUISTIC_CASING. The same comparison without these options was not tested.
What does the same name mean?
In Turkish, lowercase i has the dotted uppercase İ, and lowercase ı has the dotless uppercase I. I wanted to see whether Windows would use that linguistic rule when given two filenames.
The first contrast was izmir.txt and İZMİR.txt. The filesystem created distinct files in one directory. A tr-TR linguistic comparison returned equal. The pair izmir and IZMIR produced the reverse contrast.
How the files were created
Each pair used an empty directory. The script passed Unicode names to CreateFileW with CREATE_NEW. If the name exists, creation fails rather than opening and overwriting the existing file. Error 80 on the second creation indicated a collision.
Both AB and BA orders were tested. File identities, directory file counts and the first file's contents were checked. Volume support for case-sensitive search was recorded separately from the directory's enabled setting. All test directories had case sensitivity disabled.
Character marshalling and file-identity structure alignment were corrected in the initial script. Measurements were then repeated in clean directories. Conditions A, B and C used the same measurement script.
- elma / ELMA collided, the ASCII control.
- çorba / ÇORBA collided, the cedilla control.
- izmir / IZMIR collided.
- izmir / İZMİR created distinct files.
- ılık / ILIK created distinct files.
- ılık / İLİK created distinct files.
What the disk table said
MS-FSCC describes $UpCase as the uppercase table used for collation. It does not supply the contents of this volume's table. I read those contents from the volume itself.
The reader opened the raw volume with GENERIC_READ only and read the 131,072-byte table. That access was read-only; output files were saved on the same C drive. The calculated CRC64 matched DADC7E776B1B690C in the $Info stream.
Entry U+0069, lowercase i, maps to U+0049, uppercase I. U+0130, dotted İ, and U+0131, dotless ı, map to themselves. Across the complete table, only I and i produce I; İ and ı each have only their own preimage.
I mapped each filename's UTF-16 code units through this table and compared the results. All six pairs agreed with file creation. This agreement is different evidence from tracing the filesystem's internal execution.
The $Info field names come from the reader implementation and ntfs-3g. The reported 10.0 and 26100 values were not used to establish when the table was written or which update wrote it.
Did Turkish locales change the result?
Condition A used en-US for both user format and system locale. B changed only user format to tr-TR. C also changed the system locale for non-Unicode applications to tr-TR and required a reboot.
ANSI/OEM code pages stayed 1252/437 in B and became 1254/857 in C. Get-UICulture remained en-US throughout. This is not a measurement of changing the display language.
Each condition produced 12 decisions. The first three pairs collided in both orders and the last three created distinct files. In C, both $UpCase and $Info were byte-identical to the baseline copies.
User and system locales were restored to en-US. The post-reboot record confirmed en-US for both, LCID 0x0409, ACP 1252 and OEMCP 437.
Why the other comparison differs
Two comparisons were recorded without creating files. CompareStringOrdinal ignored case. CompareStringEx used explicit tr-TR and en-US names with 0x08000010, combining LINGUISTIC_IGNORECASE and NORM_LINGUISTIC_CASING.
Microsoft documents NORM_LINGUISTIC_CASING as selecting linguistic casing instead of filesystem rules. The measured contrast is between the chosen comparison methods. It does not show Windows applying one language rule everywhere.
The Turkish comparison treated izmir / İZMİR and ılık / ILIK as equal, but izmir / IZMIR as unequal. The English linguistic and ordinal comparisons agreed with NTFS for the six tested pairs. These API results were computations, not file-creation tests.
What this test establishes
On this volume, treating filename equality as Turkish word equality did not hold. An application deduplicating filenames with linguistic rules could classify names differently from the filesystem. Whether this causes a real application defect requires a separate test.
The original records were retained locally. The document images are crops from those recordings, with no reconstructed terminal text. The sources include a normalized JSON summary of decisions, conditions, table hashes and restored settings. It is not presented as raw logs or an NTFS execution trace.