两条路径分隔符的故事
A tale of two path separators

原始链接: https://alexwlchan.net/2021/slashes/

macOS 允许用户创建文件名中看似带有斜杠的文件,这种特性源于该系统融合的双重血统。现代 macOS 是经典 Mac OS(使用冒号作为路径分隔符)与基于 Unix 的 NeXTSTEP 系统(使用斜杠作为路径分隔符)的混合体。 为了在过渡期间保持兼容性,苹果工程师实现了一个转换层。因此,一个包含冒号的文件名,在旧版 Carbon 应用程序中可能显示为斜杠,而在现代基于 Unix 的工具或 Cocoa 应用程序中则保留为冒号。这种“精神分裂”式的特征在使用 AppleScript 时最为明显,因为 AppleScript 沿袭了 System 7 时代的习惯,默认使用冒号分隔路径。 尽管苹果在 2017 年用 APFS 取代了传统的 HFS+ 文件系统,但为了防止破坏旧版软件,这种双重分隔符的行为得以保留。对于习惯了 Unix 主导环境的用户来说,这似乎有悖常理,但这种行为是苹果努力将两种截然不同的计算架构合并为一个统一、协调的操作系统的功能性遗迹。

这份 Hacker News 讨论探讨了不同操作系统中路径分隔符的历史和技术特性。 主要内容包括: * **macOS/Classic Mac OS:** 历史上曾使用冒号 (:) 作为路径分隔符,现在在 Finder 中通常显示为正斜杠 (/)。苹果的文件系统 (APFS) 特色鲜明,采用了区分大小写和 Unicode 规范化 (NFD) 等功能,使其不同于标准的 Unix 行为。 * **Windows:** 保留了“DOS 包袱”,例如通过 `cmd.exe` 管理的传统各驱动器当前目录。它还具有独特的区域差异,例如在日语区域设置中使用日元符号 (¥) 作为路径分隔符。 * **通用复杂性:** 对话强调了路径处理通常由虚拟文件系统 (VFS) 层而非存储硬件本身决定。用户指出,虽然某些字符在 Linux 和 macOS 的文件名中技术上是“有效”的,但它们可能会引发严重的可用性或安全问题。 * **演变:** 讨论涉及了从分层文件系统向扁平结构(如 S3)的过渡,以及来自 CP/M 和 VMS 等早期系统的设计选择所产生的深远影响。
相关文章

原文

I was reminded yesterday that macOS will happily let you create files that appear to have slashes in their name, as shown here by the Finder:

A Finder window with two entries. The first is a folder named 'a/b/c' (a slash b slash c), the second is a text file named 'x/y/z' (x slash y slash z).

I made the folder with the “New Folder” button in Finder, and the text file by saving it in TextEdit. Even though I understand how this works, it breaks my brain a bit every time.

If you didn’t know how this works, you could get a clue by running ls:

$ ls
a:b:c/     x:y:z.txt

The files have either colons or slashes in their name, depending on how you look at them.

I don’t understand all the nuances, but I know this is a side-effect of the fact that macOS has not one but two path separators: the slash (/) and the colon (:). The two separators are used in different contexts, and the system will translate between them as needed.

These two separators reflect the two parent systems of modern macOS: classic Mac OS and the Unix-like NeXTSTEP. When they were joined together, Apple’s engineers had to build a file system that was compatible with both the classic Mac’s file system (the Mac OS Extended File System, aka HFS+), and with NeXTSTEP’s file system (the Unix file system, aka UFS). Among other differences, these systems had different path separators: HFS+ used a colon, while UFS used a slash.

There’s a Usenix 2000 paper written by several Apple engineers which describes the problems of combining classic Mac OS and Unix in more detail. It actually describes exactly what we’re seeing with the Finder and ls:

[The translation layer] can create a user-visible schizophrenia in the rare cases of file names containing colon characters, which appear to Carbon applications as slash characters, but to BSD programs and Cocoa applications as colons.

AppleScript is where you’re most likely to encounter colons as path separators in modern macOS:

$ which osascript
/usr/bin/osascript

$ osascript -e 'tell application "Finder" to get (path to me)'
alias Phoenix SSD:usr:bin:osascript

This is likely because AppleScript goes back to System 7, which only had to care about HFS+ and colons. It can give you a UNIX- (or POSIX-) style path, but you have to ask for it explicitly:

$ osascript -e 'tell application "Finder" to get POSIX path of (path to me)'
/usr/bin/osascript

In 2017, Apple replaced HFS+ with the Apple File System, aka APFS, but these dual path separators remain. I can’t find any documentation to confirm it, but I assume that’s for backward compatibility reasons – picking a single path separator would break an enormous amount of software.

The “slashes in filenames” breaks my brain because I started programming after Unix-style filesystems had become totally dominant. In my mind, slash is the directory separator, and Windows is weird for using the backwards slash (\). In reality, file systems have used a variety of directory separators, and it’s only the current Unix hegemony that makes this seem weird. On another timeline, forward slashes in a filename would seem totally normal.

联系我们 contact @ memedata.com