win 上哪种文件系统是区分大小写的？

其实是 windows 本身不区分大小写，，和文件系统无关

NTFS 和 FAT32 其实都是区分大小写的。。

自 Windows 10 内部版本 17107 开始，支持按目录区分大小写。 在 Windows 10 内部版本 17692 中，支持已更新，以包括从 WSL 内检查和修改目录的区分大小写标志。 使用名为 system.wsl_case_sensitive 的扩展属性公开区分大小写。 对于不区分大小写的目录，此属性的值为 0 ；对于区分大小写的目录，此属性的值为 1 。


https://docs.microsoft.com/zh-cn/windows/wsl/case-sensitivity

冷知识：NTFS 是大小写敏感的，用起来不敏感是因为 windows 包了一层

win10 上你可以对单独某个文件夹设置开启大小写敏感：
fsutil.exe file setCaseSensitiveInfo D:\workspace enable

NTFS 内部是区分大小写的，但 Windows 默认不区分。

Windows 10/11 安装 WSL 以后可以用这个命令来对 NTFS 中的个别目录激活区分大小写属性：

fsutil file setCaseSensitiveInfo 路径 enable

@wy315700 那就是说从目录着手曲线救国了，也行吧，不过还是不够方便。
每建一个文件夹都要再设置一下。万一忘记就麻烦了。

@James369 顶层目录设置一下就行了，或者干脆直接设置一个分区。

我还觉得 Linux 不够友好了, 为啥要按照大小写在 UI 层区分文件

@tsanie 我试了好像不能针对整个分区直接设置，只能对目录设置？

想全局开的话可以改注册表里的 ObCaseInsensitive ，不过印象中开了之后，还得在 CreateFile 传递 FILE_FLAG_POSIX_SEMANTICS 参数，基本上只有 Cygwin/MSYS2 会传这个参数，绝大多数应用还是不会生效的。而且我这里开了之后蓝牙用不了，印象中是蓝牙开关点了没反应。
至于楼上说的 fsutil setCaseSensitiveInfo 是否需要传递 FILE_FLAG_POSIX_SEMANTICS 我就不知道了。

@James369 对目录设置了之后在里面创建子目录是自动继承设置的。

@James369 不过这里还是有个问题，虽然直接创建目录是继承设置，但是第三方软件创建目录却不一定。如果你用的 Windows 里的压缩软件没有适配这个功能的话，解压出来的目录仍然是不区分大小写的，还是不能解压。为保险起见最好还是在 WSL 里解压这种压缩包。

macOS 虽然可以设置,但是你架不住软件不适配.打开大小写敏感,很多软件崩的六亲不认.

@nieyujiang macOS 要区分大小写的话有个曲线救国的方案是创建虚拟磁盘，然后把虚拟磁盘格式化为区分大小写的文件系统。

大小写敏感并不是好事，冷知识：steam 的启动脚本里面用的文件名全是小写，但是目录下的文件名则各有不同。这就导致 steam 安装在大小写敏感的盘上无法启动。

@Mutoo Windows 环境变量里 C:\WINDOWS 全是大写的，改了 C 盘估计系统都启动不了。

NTFS 是区分大小写的，这个和 macOS 是反的，Mac 是文件系统默认不分大小写，操作系统分大小写。不过这两个要强行改估计都一堆坑。

@nieyujiang #11
我倒是把 macOS 的大小写敏感打开用了几年了，除了 Steam 还没遇到过不兼容的软件。不过 macOS 上的 Steam 本来也是个残废就是了。

用大小写来区分文件才是真蛋疼

mac 我用了几年的区分大小写了，除了 abobe （用另一个忘了叫啥了替代） 和 steam （这个几步忽略，正经人谁用 steam 在 mac ）

@lxml 真的, 我也用区分大小写, 主要是为了编译安卓系统方便, 但是 PS 和 steam 装不了, 真的挺蛋疼的

前几年折腾黑果的时候有一次把硬盘格成 APFS caps-sensitive

结果装好了各种第三方软件报错

@mineralsalt #19 我倒是没啥刚需，主要是就是强迫症，另外就是 NAS 上偶尔有一些 docker 里面有大小写相关的问题

另外，mac 以后改成区分大小写也不奇怪，因为 iOS 是区分的，macOS 不区分我感觉是当时的一个设计失误吧，而且以 mac 拨乱反正的能力，cpu 都换几次了，换个大小写敏感不是什么难题

Steam 在 Linux 上好好的，不知道为啥 ...
目前在 Linux 上区分大小写碰到的唯一兼容问题就是 Civ6 的 mod 不好装，需要改下配置文件。

理论上大小写不敏感的系统更安全，大小写敏感的文件碰到了大小写不敏感的系统有可能会出问题，但大小写不敏感的文件碰到大小写的敏感系统一定不会出问题。

最早的 unix 是区分大小写的，但你看后来 linux 就不区分，基于 freebsd 的 macOS 也算是正宗 unix 了，但它也不区分大小写。这说明啥，说明区分大小写坑人啊。

区分大小写才好阿 命名规范
想要不敏感改下 mount 参数以及 /etc/fstab 就可以

从系统开发的角度，不区分大小写可以简化问题

@Huelse

是简化了 但又产生了新的问题 看代码总是耗眼力

@AX5N #24 一个文件夹里有 A 和 a 两个文件，炸

个人来说，喜欢 Linux 区分大小写的设计，但考虑收益，在重装 macos 时我选了 case-insensitive 的。
1 、大小写不敏感的设计并没有给我带来太多负面影响，因为绝大多数情况下，我都不会建两个只有大小写有差别的文件（如果不是有人提，我可能一辈子不会注意到 windows 和 macos 是大小写不敏感的，毕竟大小写不敏感不等于没有大小写）
2 、如其它人说的，macos 上 steam 等软件可能会在 Case-sensitive 的环境中出现问题，这是一个明显的减分项
3 、考虑到 macos 和 windows 默认都是大小写不敏感的，那么也就意味着其它人的电脑最有可能是大小写不敏感的，那即使我在用 Linux ，也会尽量避免分享给别人 a 和 A 这样的两个文件
4 、建立 Git 仓库时、npm init 时、设计 api 时，写 maven 的 groupId 时，一般建议使用中划线命名法，所以我大概也已经习惯了
总体来说，我个人感觉，大小写不敏感的设置不会对开发造成明显影响。调整一下你自己的命名方法可能相对来说更好、更方便，收益更佳

@dcsuibian
习惯好怎么写都不差
但依照一堆过往看过的命名就只能说区分还是比较好

@learningman 为何要有 A 和 a 两个文件夹,直接就一个 A 或 a 文件夹就可以了,多此一举,浪费资源!

@chtcrack #32 别问我，反正有人这么做了，你如果你用了他写的代码就会炸，你自己选择

@learningman 我的选择,不用他的代码,自己写..

@chtcrack #34 你总要用第三方库，你总要 import ，你总会有依赖，指不定哪里就炸了

@chtcrack #34 比如 WSL1 的时候，很多东西在上面编译不出来，就因为大小写不敏感

linux 才是最威的，本就分大小

@AX5N
大小写敏感的文件碰到了「大小写不敏感的系统」有可能会出问题，为什么会推论出「大小写不敏感的系统」更安全？

@duke807 我觉得 Oberon 和 Multisys 才是权威的，但我不知道它们是否区分大小写……

@2i2Re2PLMaDnghL 操作系统还会包含各种子系统（你的程序），如果你的程序在你的操作系统运行出现问题，不就说明你的操作系统容易诞生问题（不安全）吗。

@AX5N 所以应该是『更不安全』而不是『更安全』啊
（所以说你只是单纯笔误写反了是吗

@2i2Re2PLMaDnghL 没写反啊，我只是用敏感的系统做例子而已，反过来就是不敏感的系统诞生不敏感的文件，不敏感的文件在任何系统里都不会存在问题，不就是更安全吗。