A problem: it’s possible for two non-identical Unicode strings to correspond to the same sequence of characters. Windows, Linux, and Macintosh all support Unicode in paths Windows encodes them as UTF-16 in all of its native APIs, whereas Linux and Macintosh use UTF-8. The issue of case sensitivity brings up another issue: internationalization. More recently, Apple now allows HFS to be formatted either way, as either case-sensitive or case-insensitive, but the default remains case-insensitive. The Macintosh is now Unix-based as of OSX, but its HFS file system has traditionally been case-insensitive and case-preserving, just like Windows. Some Windows file systems, like the original FAT, aren’t even case-preserving.
#Hfs file system windows manager how to#
It’s really up to the individual file system to decide how to interpret all these flags, though.
By setting or not setting OBJ_CASE_INSENSITIVE, you can select which type of name lookup you prefer. Check out the documentation for the NtCreateFile API, the native NT API that the Win32 API CreateFile maps to. Or, at least it looks like Windows does! But in reality Windows supports both. Windows has a case-preserving but case-insensitive file system. Let’s start with the most obvious one: case sensitivity. Some of these differences are well-known and obvious, but there are a lot of other interesting differences underneath the covers, especially when you get down into the file system driver kernel interfaces. One of the challenges in implementing a cross-platform file system driver such as Cascade File System is dealing with the many differences, small and large, between how Windows, Linux, and Macintosh file systems work.
0 kommentar(er)
