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?

Thread beginning with comment 657774
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[13]: Well...
by malxau on Fri 1st Jun 2018 02:47 UTC in reply to "RE[12]: Well..."
Member since:

It is in fact required because there is a nice little issue with case insensitive due to the upper and lower case being bases on local setting not written to early NTFS so you had a drive from a different country/locale setting install of Windows and you could have problems seeing the files.

I'm skeptical about this. I see the Upcase file being written to disk as early as 1992, before the first release of NT. I think the real issue in the whole design is that an application cannot call stricmp (using whatever Unicode table/locale is in effect for that application) and assume that NTFS will resolve things the same way. However, this is something applications often want/need to do, which makes writing "correct" code all but impossible.

XP the work around was formalised. But I do agree Windows implementation of case sensitive and case insensitive can be highly random at times what happens.

The XP change was mainly a security change to avoid squatting attacks where insensitive openers could be tricked into opening an attacker's file.

You do see overhead on NTFS when applications are stupid and don't keep their case constant. Yes case insensitive is on by default but the fast path is always the case sensitive look up.

I don't believe this is true and this thread has gone into a lot of detail as to why. A file called "a" is collated before "B". If an open for a file on disk that is called "a" arrives as "a", it still needs to be upcased to "A" to locate the file in the index. The fact that case matches won't make the index lookup any faster, because the index lookup isn't based on the original case of the file. The only time a case sensitive compare needs to occur is to open a file in case sensitive mode - ie., this is purely a performance tax on case sensitive operations. I'd really love to see a benchmark that shows case sensitive being faster, because all the code I've seen will not behave that way.

I could believe there is other code in the universe that has such a "fast path" (eg. a case sensitive hash table based cache) which causes case mismatch to trigger a slow path, but that is not code in NTFS.

Reply Parent Score: 3

RE[14]: Well...
by galvanash on Fri 1st Jun 2018 19:28 in reply to "RE[13]: Well..."
galvanash Member since:

That's why I love discussions like this on osnews... I felt like I knew a bit about how NTFS worked, only to find out my knowledge only scratched the surface.

Thanks for all the info everyone.

Reply Parent Score: 3