区分大小写的系统上安装 Adobe 系列真的不可能吗？

[phoulx]

上次抹盘升级 Catalina 的时候，故意选择了 case-sensitive （并非工作需要，衹是觉得这样比较舒服），一直用着也没问题，像 OneDrive 和 Steam，虽然不能直接用，但 app 本身是可以直接装的，衹要另外建一个 case-insensitive Volume，再软链接一下文件夹，就可以正常使用。
但 Adobe 系列真是恶心了，官网下载的 dmg，打开後直接不能装，提示不支持 case-sensitive Volume，让我重选一个 Volume，可下面就一个「 Quit 」，根本不给我选择安装到哪个 Volume 。

在网上搜到有人给了解决方案，不过是好几年前了： https://github.com/tzvetkoff/adobe_case_sensitive_volumes
大致是通过创建一个 SparseBundle Volume，然後 Makefile 编译一个文件以欺骗 Adobe 的检查宗卷大小写的操作。我照着步骤尝试了下，并且参考了两位网友的改进，但最终还是失败，可能原因是所用到的 FSGetVolumeParms 方法已经失效，不知道 macOS 现在有什么 API 可以获取磁盘信息，也不清楚 Adobe 现在是如何检查分区的。

因为对 macOS 系统层面不熟悉，所以基本放弃了。但要我抹盘重新选择不区分大小写，肯定是不可能的。现在打算开一个 case-insensitive Volume 新装一个 macOS beta，再在上面装 Adobe 系列，顺便体验一下 Big Sur 吧。

感谢@des 的建议，我在新开的case-insensitive Volume装了另一个macOS系统（尝试装Big Sur失败，所以还是装了Catalina），并在其上安装了Lightroom（过程中自动给我装了Creative Clouds），之後回到原来的系统，将新系统/Applications/Lightroom.app复制过来，就直接可以使用，但是不能更新，因为更新由Creative Clouds来做。

所以我又将Creative Clouds那一堆文件（包括/Applications/Utilities和/Library/Application Support/Adobe两个地方，如果单独复制主程序则无法打开）复制到原系统的相应位置，也可以正常使用，但是下载新app如Photoshop会报错，因为默认的下载位置属于case-sensitive Volume。

这时衹需打开Creative Clouds的设置，将安装位置改为某个case-insensitive Volume文件夹（其後不能再改回来），就可以在Creative Clouds界面下载安装其他apps了，问题得到解决（至少表面上）。

所以，目前在区分大小写的系统上安装使用Adobe系列是可行的。方法：

• 如果衹要用到某一个app（如Lightroom），并且不需更新，那从另一个安装好Adobe的系统（可以是另一个宗卷、虚拟机或另一台电脑）将所要的app复制过来即可使用；
• 如果要用到一系列Adobe apps，或者需要自带的程序更新，那么最好从另一个安装好Adobe的系统将Creative Clouds及相关文件复制到原系统，设置好安装路径，再经由Creative Clouds安装即可。

赞美太阳！

[vk42]

这个真是的 MacOS 的一个大槽点，设计简直无语了……

[zvcs]

区分大小写的磁盘分区也不能安装战网。

[tianshilei1992]

@vk42 我认为这个不是 macOS 的问题，而是应用程序的问题。case-sensitive 不是简单的我们理解的英语的大小写，请参考 https://www.quora.com/Why-does-OS-X-choose-to-have-a-case-insensitive-file-system-instead-of-a-case-sensitive-one

[pocarisweat]

@tianshilei1992 学习了，多谢

[vk42]

@tianshilei1992 不太赞同这个问题仅仅是应用的锅，而且这和字符集没关系啊
可以参考下 Win 10 的做法，NTFS 本质是 case sensitive 的，但是通过 API 层提供了 case insensitive 的语义来保持兼容性。

[ipwx]

@vk42 这样慢吧。。。

[ipwx]

u1s1 一个 case insensitive 的文件系统你把它当 case sensitive 用不就好了，为什么一定要倒过来呢？

[vk42]

@ipwx 这和慢不慢有什么关系，无非是在文件系统层统一化还是在 API 层统一化。Windows 默认行为都是 case insensitive 的，只有 WSL 等需要 case sensitive 才会用
怎么把 case insensitive 的文件系统当 case sensitive 用？同时有 case, Case 两个文件，你要给 Case 起个别名？

[lxilu]

@vk42 不完全是 API 兼容吧，NTFS 能设置文件夹 CI/CS 的。

[phoulx]

@vk42 他的意思大概是让用户自己避免这种文件命名⋯

[vk42]

@lxilu 不清楚你说的能设置文件夹 CI/CS 和 API 兼容有什么关系……

[phoulx]

@ipwx 因为生命在于折腾⋯当时想着即使出问题也应该可以解决，就像 OneDrive 那样软链接啥的，谁料到 Adobe 完全不给人机会⋯

[des]

@phoulx
真的是烦他们这种的，你找个同样版本的 macos
在虚拟机里面装好了，把新加的文件复制出来就完事了

[des]

贴一下，有这几个地方需要复制
/Library/Application Support/Adobe
/Library/Internet Plug-Ins/AdobeAAMDetect.plugin
以及 Applications 里面的主程序和 Utilities

好像是还有一个文件，需要复制出来，不然每次会弹提示，不过不影响使用
另外推荐一下 Krita

[phoulx]

@des 谢谢，我今天就在想是不是从安装好的机器复制 app 出来就可以用，回头试试。然後我主要用 Lightroom，管理照片方便。

[alphatoad]

Case sensitive 应当是 case insensitive 子集或者说 narrower version，为什么应用程序不默认 case sensitive ？这样应当总是安全的

[tianshilei1992]

@vk42 这个问题难道不应该是，应用程序应该根据 volumes 是否是 case-sensitive 做不同的操作吗？为什么应用程序一定要假设 volumes 是 case-insensitive 的呢？应用程序应该调用 OS 提供的 API，那么既然 volumes 是 case-sensitive 的，为什么要提供一套 case-insensitive 的 API ？

[shutongxinq]

希望这波 macOS 大换代把这个 case-insensitive 的问题理顺了。case-insensitive 真的蛋疼。

[jin7]

一切都默认 就很轻松了

[Mutoo]

Steam 的问题之前也遇到了：
https://blog.mutoo.im/2017/09/caveats-with-filesystem/

「装了 Steam 后发现怎么也打不开，一直卡在登陆界面。通过终端运行 Steam，看到了打印出来的日志：

Errors in public/subpanelwelcomeintro.res:
error loading file 'public/subpanelwelcomeintro.res', no such file
Errors in public/subpanelwelcomecreatenewaccount.res:
error loading file 'public/subpanelwelcomecreatenewaccount.res', no such file
Errors in public/subpanelwelcomecreatenewaccountaccountname.res:
error loading file 'public/subpanelwelcomecreatenewaccountaccountname.res', no such file
Errors in public/subpanelwelcomecreatenewaccountemail.res:
error loading file 'public/subpanelwelcomecreatenewaccountemail.res', no such file
...
才发现 Steam 的加载器全部以小写文件名加载文件，而目录中的文件名则是驼峰式的，（ e.g. SubPanelWelcomeIntro.res ）。只好暂时写个脚本将所有文件名转成小写，终于可以正常打开 Steam 了。」

[ipwx]

@vk42

> 怎么把 case insensitive 的文件系统当 case sensitive 用？同时有 case, Case 两个文件，你要给 Case 起个别名？

我的意思是你无论自己创建文件，还是写程序创建文件，都避免创建这种不同 case 相同名称的文件。如果你自己恪守这种准则，那么日常体验中不会感觉它是 case insensitive 的文件。这就是我所谓的“把 case insensitive 的文件系统当 case sensitive 用”。实际上这是一种良好而且必要的行为准则，如果你还要用 Windoge 的话。而且你写程序的话，保证 Windoge 通用性也是好习惯吧？

> 这和慢不慢有什么关系，无非是在文件系统层统一化还是在 API 层统一化。

如果 FS 底层没有记录 case insensitive 的信息，你要让 FS 在应用层面去寻找相同文件名，那么你就需要 O(n) 的比对。不然就可以通过散列等方式优化寻址。当然，各个 FS 有没有做我不知道，但是至少这种时间开销上的差距，理论上是存在的。

[vk42]

@tianshilei1992 主要是兼容性问题，默认系统是 CI 的话，有些应用可能对文件名大小写没那么注意，举个例子一个 app 在一个地方用 Case.txt 为文件名写出去的文件，另一个地方按 case.txt 打开，在 CS 的系统上就会报找不到文件……

[vk42]

@ipwx
这个你得跟 Adobe 和 Steam 他们说去啊，用户又没得选……

这个性能问题确实可能存在，不太清楚 NTFS 实际怎么实现的，应该是在文件 metadata 里面加上 CI 信息。看了下 WINE 在 CS 文件系统上实现时也有类似问题： https://wiki.winehq.org/Case_Insensitive_Filenames

[tianshilei1992]

@vk42 所以说还是应用程序的问题，是应用程序本身就没有按照系统的规则来…

[MaxLi77]

没必要全盘区分大小写，apfs 可以分配一块共享的 区分大小写的 空间。开发者自己程序不规范，你也没法解决，别给自己找麻烦。。

[TrickerPan]

@ipwx

你不是程序猿吧？

1. 实际程序在编译的时候，大写和小写区别很大，case insensitive 创建文件夹默认全字母小写，你认为你的文件名是驼峰，实际上呵呵呵。
2. 现在服务器基本都是 Linux 的，用了 CVS 自动帮你转换了还行，不转换的话就很有意思了。我遇到过有人用 case insensitive，创建文件的时候，手快了全打成了小写，然后重命名了，传到服务器上死活找不到这个文件了。结果看了下 log，人家在服务器上还是小写。
3. 不要说规范啊、习惯啊什么的，谁还没个手误的时候？

所以 case insensitive 不能当作 case sensitive 来用。