这是一个创建于 1048 天前的主题，其中的信息可能已经有所发展或是发生改变。
win 上对开发真是不够友好，这年头 NTFS 还是不区分大小写，解压一个包都报重名错误（大小写不一样）。 蛋疼，至少 mac 在新建文件系统时，也可以选择是否区分大小写。 怎么处理呢，各位大神。
 |
1
wy315700 2022-01-12 16:52:49 +08:00  7
其实是 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 |
 |
2
lcdtyph 2022-01-12 16:53:31 +08:00 via iPhone 9
冷知识：NTFS 是大小写敏感的，用起来不敏感是因为 windows 包了一层
win10 上你可以对单独某个文件夹设置开启大小写敏感： fsutil.exe file setCaseSensitiveInfo D:\workspace enable |
 |
3
qbqbqbqb 2022-01-12 16:57:07 +08:00 1
NTFS 内部是区分大小写的，但 Windows 默认不区分。
Windows 10/11 安装 WSL 以后可以用这个命令来对 NTFS 中的个别目录激活区分大小写属性： fsutil file setCaseSensitiveInfo 路径 enable |
 |
4
James369 OP @wy315700 那就是说从目录着手曲线救国了，也行吧，不过还是不够方便。
每建一个文件夹都要再设置一下。万一忘记就麻烦了。 |
 |
6
thinkershare 2022-01-12 18:01:56 +08:00
我还觉得 Linux 不够友好了, 为啥要按照大小写在 UI 层区分文件
|
 |
8
ysc3839 2022-01-12 19:04:57 +08:00
想全局开的话可以改注册表里的 ObCaseInsensitive ，不过印象中开了之后，还得在 CreateFile 传递 FILE_FLAG_POSIX_SEMANTICS 参数，基本上只有 Cygwin/MSYS2 会传这个参数，绝大多数应用还是不会生效的。而且我这里开了之后蓝牙用不了，印象中是蓝牙开关点了没反应。
至于楼上说的 fsutil setCaseSensitiveInfo 是否需要传递 FILE_FLAG_POSIX_SEMANTICS 我就不知道了。 |
|
10
qbqbqbqb 2022-01-12 19:32:28 +08:00
@James369 不过这里还是有个问题，虽然直接创建目录是继承设置，但是第三方软件创建目录却不一定。如果你用的 Windows 里的压缩软件没有适配这个功能的话，解压出来的目录仍然是不区分大小写的，还是不能解压。为保险起见最好还是在 WSL 里解压这种压缩包。
|
 |
11
nieyujiang 2022-01-12 19:44:37 +08:00
macOS 虽然可以设置,但是你架不住软件不适配.打开大小写敏感,很多软件崩的六亲不认.
|
|
12
ysc3839 2022-01-12 19:45:36 +08:00
@nieyujiang macOS 要区分大小写的话有个曲线救国的方案是创建虚拟磁盘，然后把虚拟磁盘格式化为区分大小写的文件系统。
|
 |
13
Mutoo 2022-01-12 20:07:45 +08:00 via iPhone
大小写敏感并不是好事，冷知识：steam 的启动脚本里面用的文件名全是小写，但是目录下的文件名则各有不同。这就导致 steam 安装在大小写敏感的盘上无法启动。
|
 |
15
agagega 2022-01-12 20:27:38 +08:00 via iPhone
NTFS 是区分大小写的，这个和 macOS 是反的，Mac 是文件系统默认不分大小写，操作系统分大小写。不过这两个要强行改估计都一堆坑。
|
 |
16
hronro 2022-01-12 20:49:09 +08:00
@nieyujiang #11
我倒是把 macOS 的大小写敏感打开用了几年了，除了 Steam 还没遇到过不兼容的软件。不过 macOS 上的 Steam 本来也是个残废就是了。 |
 |
17
tuwulin365 2022-01-12 22:40:04 +08:00 4
用大小写来区分文件才是真蛋疼
|
 |
18
lxml 2022-01-12 23:13:38 +08:00 via Android
mac 我用了几年的区分大小写了，除了 abobe （用另一个忘了叫啥了替代） 和 steam （这个几步忽略，正经人谁用 steam 在 mac ）
|
 |
19
mineralsalt 2022-01-12 23:17:15 +08:00
@lxml 真的, 我也用区分大小写, 主要是为了编译安卓系统方便, 但是 PS 和 steam 装不了, 真的挺蛋疼的
|
 |
20
datou 2022-01-12 23:20:12 +08:00
前几年折腾黑果的时候有一次把硬盘格成 APFS caps-sensitive
结果装好了各种第三方软件报错 |
|
21
lxml 2022-01-12 23:22:31 +08:00
@mineralsalt #19 我倒是没啥刚需，主要是就是强迫症，另外就是 NAS 上偶尔有一些 docker 里面有大小写相关的问题
|
|
22
lxml 2022-01-12 23:23:18 +08:00
另外，mac 以后改成区分大小写也不奇怪，因为 iOS 是区分的，macOS 不区分我感觉是当时的一个设计失误吧，而且以 mac 拨乱反正的能力，cpu 都换几次了，换个大小写敏感不是什么难题
|
 |
23
secondwtq 2022-01-13 03:19:13 +08:00
Steam 在 Linux 上好好的，不知道为啥 ...
目前在 Linux 上区分大小写碰到的唯一兼容问题就是 Civ6 的 mod 不好装，需要改下配置文件。 |
 |
24
AX5N 2022-01-13 04:30:11 +08:00
理论上大小写不敏感的系统更安全，大小写敏感的文件碰到了大小写不敏感的系统有可能会出问题，但大小写不敏感的文件碰到大小写的敏感的系统一定不会出问题。
|
 |
25
xuanbg 2022-01-13 09:20:24 +08:00
最早的 unix 是区分大小写的，但你看后来 linux 就不区分，基于 freebsd 的 macOS 也算是正宗 unix 了，但它也不区分大小写。这说明啥，说明区分大小写坑人啊。
|
 |
26
james122333 2022-01-13 09:50:37 +08:00
区分大小写才好阿 命名规范
想要不敏感改下 mount 参数以及 /etc/fstab 就可以 |
 |
27
Huelse 2022-01-13 11:13:58 +08:00
从系统开发的角度，不区分大小写可以简化问题
|
|
28
james122333 2022-01-13 11:45:02 +08:00
|
 |
29
learningman 2022-01-13 11:58:38 +08:00
@AX5N #24 一个文件夹里有 A 和 a 两个文件，炸
|
 |
30
dcsuibian 2022-01-13 13:35:28 +08:00
个人来说，喜欢 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 时，一般建议使用中划线命名法，所以我大概也已经习惯了 总体来说，我个人感觉，大小写不敏感的设置不会对开发造成明显影响。调整一下你自己的命名方法可能相对来说更好、更方便，收益更佳 |
|
31
james122333 2022-01-13 16:07:19 +08:00
|
 |
32
chtcrack 2022-01-13 16:39:54 +08:00
@learningman 为何要有 A 和 a 两个文件夹,直接就一个 A 或 a 文件夹就可以了,多此一举,浪费资源!
|
|
33
learningman 2022-01-13 16:52:32 +08:00
@chtcrack #32 别问我，反正有人这么做了，你如果你用了他写的代码就会炸，你自己选择
|
|
34
chtcrack 2022-01-13 17:09:23 +08:00
@learningman 我的选择,不用他的代码,自己写..
|
|
35
learningman 2022-01-13 17:12:39 +08:00
@chtcrack #34 你总要用第三方库，你总要 import ，你总会有依赖，指不定哪里就炸了
|
|
36
learningman 2022-01-13 17:13:18 +08:00
@chtcrack #34 比如 WSL1 的时候，很多东西在上面编译不出来，就因为大小写不敏感
|
 |
37
duke807 2022-01-13 21:40:18 +08:00 via Android
linux 才是最權威的，本就應該區分大小寫
|
 |
38
2i2Re2PLMaDnghL 2022-01-14 15:48:37 +08:00
@AX5N
大小写敏感的文件碰到了「大小写不敏感的系统」有可能会出问题，为什么会推论出「大小写不敏感的系统」更安全？ |
|
39
2i2Re2PLMaDnghL 2022-01-14 15:49:45 +08:00
@duke807 我觉得 Oberon 和 Multisys 才是权威的，但我不知道它们是否区分大小写……
|
|
40
AX5N 2022-01-14 16:41:13 +08:00
@2i2Re2PLMaDnghL 操作系统还会包含各种子系统（你的程序），如果你的程序在你的操作系统运行出现问题，不就说明你的操作系统容易诞生问题（不安全）吗。
|
|
41
2i2Re2PLMaDnghL 2022-01-14 19:10:13 +08:00
@AX5N 所以应该是『更不安全』而不是『更安全』啊
（所以说你只是单纯笔误写反了是吗 |
|
42
AX5N 2022-01-14 21:32:42 +08:00
@2i2Re2PLMaDnghL 没写反啊，我只是用敏感的系统做例子而已，反过来就是不敏感的系统诞生不敏感的文件，不敏感的文件在任何系统里都不会存在问题，不就是更安全吗。
|
Select Language