Linked by Thom Holwerda on Tue 29th May 2018 23:29 UTC

Although you can now run a number of Linux distros natively on Windows 10, this integration has been a little tricky when it comes to handling filename case, as Linux is case sensitive and Windows is not.

In order to overcome this limitation, starting with the Windows 10 April 2018 Update (version 1803), NTFS includes a new flag that you can enable on a per-folder basis allowing the file system to treat files and folders as case sensitive.

I'm sure there are countless technical reasons as to why case sensitive is the preferred route to go, but is there a case to be made for case insensitivity being simpler and less confusing to use?

Permalink for comment 657766
To read all comments associated with this story, please click here.
RE[13]: Well...
by malxau on Fri 1st Jun 2018 01:13 UTC in reply to "RE[12]: Well..."
Member since:

[T]he physical organization of NTFS indexes on disk is dependent upon unicode international case mappings. Different versions of windows have updated this mapping over time to accommodate unicode additions. This is NOT a property of case sensitive file systems. Ext3 doesn't even consider what characters mean according to unicode, it's just bytes. The NTFS indexes on the other hand have a hard dependency on the meaning of letters from the unicode standard. Future letter code points would require updates to the mapping used by NTFS, Agreed?

Roughly, yes. Each NTFS volume has a $Upcase file that specifies the mapping in use by that volume. Volumes formatted on different systems will be collated using a different version of the unicode mapping table. Indeed, it'd be a valid NTFS volume that has an $Upcase table where nothing is upcased, and the result would collate like ext3. But note the effect of this is the directories are always collated in a fixed way that will not change for the lifetime of the volume (without major surgery.)

I'd be curious if you have any opinions on how the open source NTFS driver got things right or wrong? I'm guessing all the open source code came about through reverse engineering.

I have the opposite problem, I don't want to look at this particular piece of open source code, which makes comparison difficult. What I'm hearing though, which your earlier posts appeared to imply, is that it's not applying $Upcase from the volume at all and is assuming the current system Unicode table matches the collation order on the volume. This would be wrong/dangerous, but without carefully looking at the code, I'm not certain that's what's happening.

Reply Parent Score: 3