为什么 ext4 中需要不区分大小写的选项？

Question 1

不区分大小写的文件系统使我们能够解决从其他操作系统移植应用程序的重要瓶颈

没有打动我的心，我无法理解规范化和案例折叠的过程如何让我们优化磁盘存储。

葡萄酒、Samba 和 Android有提供不区分大小写的文件系统语义。如果底层文件系统区分大小写，则每次区分大小写的查找都会失败，Wine 等人。必须扫描每个目录以证明不存在不区分大小写的匹配项（例如，如果查找失败，则必须对、和中的所有文件和所有目录/foo/bar/readme.txt执行完整的目录列表和大小写比较）。foo/bar/*foo/*/*

这有几个问题：

深度嵌套的路径可能会变得非常慢（这可能会生成数百个 FS 调用）或包含数万个文件的目录（即通过 SMB 存储增量备份）。
这些检查引入了竞争条件。
它从根本上来说是不合理的：如果和都readme.txt存在README.txt，但应用程序要求README.TXT，则返回哪个文件是未定义的。

Android 甚至使用 FUSE/wrapfs 模拟不区分大小写，然后使用内核SD卡FS。然而，SDCardFS 只是通过将进程移至内核空间† 来使一切变得更快。它仍然必须遍历文件系统（因此受到 IO 限制），引入了竞争条件，并且从根本上来说是不健全的。因此，为什么 Google 资助†开发 F2FS 中的本机每个目录不区分大小写，并已弃用SD卡FS。

过去曾多次尝试通过 VFS 启用不区分大小写的查找。 2018 年的最近一次尝试允许安装文件系统的不区分大小写视图。 Ted Tso 特别提到了添加此功能时wrappfs 的问题，因为它至少会更快并且（我相信）没有竞争条件。然而，它仍然不健全（请求README.TXT可以返回readme.txt或README.txt）。这被拒绝了，而只是添加对不区分大小写的每个目录的支持，并且不太可能将其纳入 VFS††。

此外，用户期望不区分大小写，因此任何面向消费者的操作系统都必须提供它。 Unix 本身无法支持它，因为 Unicode 不存在并且字符串只是字节包。对于案件折叠的处理方式有很多有效的批评在过去，但是 Unicode 提供了一个不可变的案例折叠功能这对所有人都有效，除了单一语言环境（突厥语，即使如此，它也只是两个代码点）。还有文件系统 B 树是实施此行为的唯一合理地点。

†亚洲信息通信技术协会
††我给 Krisman 发了电子邮件，他是 EXT4 和 F2FS 上基于 VFS 的不区分大小写查找和按目录不区分大小写支持的作者。

Answer

不区分大小写的文件系统使我们能够解决从其他操作系统移植应用程序的重要瓶颈

没有打动我的心，我无法理解规范化和案例折叠的过程如何让我们优化磁盘存储。

葡萄酒、Samba 和 Android有提供不区分大小写的文件系统语义。如果底层文件系统区分大小写，则每次区分大小写的查找都会失败，Wine 等人。必须扫描每个目录以证明不存在不区分大小写的匹配项（例如，如果查找失败，则必须对、和中的所有文件和所有目录/foo/bar/readme.txt执行完整的目录列表和大小写比较）。foo/bar/*foo/*/*

这有几个问题：

深度嵌套的路径可能会变得非常慢（这可能会生成数百个 FS 调用）或包含数万个文件的目录（即通过 SMB 存储增量备份）。
这些检查引入了竞争条件。
它从根本上来说是不合理的：如果和都readme.txt存在README.txt，但应用程序要求README.TXT，则返回哪个文件是未定义的。

Android 甚至使用 FUSE/wrapfs 模拟不区分大小写，然后使用内核SD卡FS。然而，SDCardFS 只是通过将进程移至内核空间† 来使一切变得更快。它仍然必须遍历文件系统（因此受到 IO 限制），引入了竞争条件，并且从根本上来说是不健全的。因此，为什么 Google 资助†开发 F2FS 中的本机每个目录不区分大小写，并已弃用SD卡FS。

过去曾多次尝试通过 VFS 启用不区分大小写的查找。 2018 年的最近一次尝试允许安装文件系统的不区分大小写视图。 Ted Tso 特别提到了添加此功能时wrappfs 的问题，因为它至少会更快并且（我相信）没有竞争条件。然而，它仍然不健全（请求README.TXT可以返回readme.txt或README.txt）。这被拒绝了，而只是添加对不区分大小写的每个目录的支持，并且不太可能将其纳入 VFS††。

此外，用户期望不区分大小写，因此任何面向消费者的操作系统都必须提供它。 Unix 本身无法支持它，因为 Unicode 不存在并且字符串只是字节包。对于案件折叠的处理方式有很多有效的批评在过去，但是 Unicode 提供了一个不可变的案例折叠功能这对所有人都有效，除了单一语言环境（突厥语，即使如此，它也只是两个代码点）。还有文件系统 B 树是实施此行为的唯一合理地点。

†亚洲信息通信技术协会
††我给 Krisman 发了电子邮件，他是 EXT4 和 F2FS 上基于 VFS 的不区分大小写查找和按目录不区分大小写支持的作者。

Question 2

其他操作系统具有不区分大小写的文件系统。

例如：MacOS 允许不区分大小写（默认）或区分大小写。 Adobe Photoshop 和 Adobe Lightroom 不能很好地处理区分大小写的文件系统。这意味着在 Adobe 程序中，可能存在以不同方式编写的硬编码路径（可能是不同库中的“文档”和“文档”，或者只是有时应用了一些过滤器（例如小写和删除空格，这可能与数据的路径）。没有人关心，因为它只是工作。

因此，如果现在您想移植为我们时代的某些常见专有操作系统制作的程序，您应该修复所有路径，以便始终一致地使用文件名大小写，或者您更喜欢有一个处理这些情况的文件系统为你。

Adobe 无法在 MacOS 上做到这一点，因此对于其他供应商来说，事情会更加困难（而且成本高昂）。看https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html

Answer