//foo/bar 在哪些系统上与 /foo/bar 不同?

//foo/bar 在哪些系统上与 /foo/bar 不同?

在整个 POSIX 规范中,有这样的规定 (1,2,3...) 允许实现特殊地处理以 2 开头的路径/

POSIX 应用程序(按照 POSIX 规范编写的可移植到所有 POSIX 兼容系统的应用程序)不能假设 与//foo/bar相同/foo/bar(尽管它们可以假设 与///foo/bar相同/foo/bar)。

现在,那些专门处理的 POSIX 系统(历史上的且仍在维护的)是什么//foo?我相信(我现在被证明是错误的)POSIX 规定是由 Microsoft 为其 Unix 变体(XENIX)以及可能的 Windows POSIX 层推动的(任何人都可以证实这一点吗?)。

它由 Cygwin 使用,Cygwin 也是 Microsoft Windows 的类似 POSIX 的层。是否有非 Microsoft Windows 系统?开放虚拟管理系统?

系统中哪些地方//foo/bar比较特殊,它的用途是什么?//host/path用于网络文件系统访问?虚拟文件系统?

做一些应用在类 Unix 上运行(如果不是系统的 API)会//foo/bar特殊对待路径(在它们否则视为/foo/bar文件系统上的路径的上下文中)?


编辑,我从那时起在奥斯汀集团邮件列表上提出了一个问题关于规范中处理的起源//foo/bar,并且讨论是一个有趣的阅读(至少从考古学的角度来看)。

答案1

这是迄今为止给出的答案的汇编和索引。这篇文章是社区维基,任何拥有 100+ 声望的人都可以编辑它,并且没有人从中获得声望。请随意发布您自己的答案并在此处添加指向它的链接(或等我这样做)。理想情况下,这个答案应该只是一个摘要(包含简短的条目,而其他个别答案则包含详细信息)。

目前积极维护的系统:

已失效的系统

//foo/bar专门处理路径的应用程序

答案2

某些在类 Unix 上运行的应用程序(如果不是系统的 API)是否会特殊对待 //foo/bar 路径?

我知道 Perforce 使用//depot/A/B/C/D路径来引用 Depot。//Client/C/D当客户端指向//depot/A/B/.Perforce时, Perforce 还支持路径。这里,本地文件系统可能没有这些路径。

p4 filelog //depot/A/B/C/D即使没有 file ,也会显示该文件的历史记录/depot/A/B/C/D

p4 filelog C/D如果从适当的目录执行,还将显示该文件的历史记录。

参考 :https://www.perforce.com/perforce/r12.1/manuals/cmdref/o.fspecs.html

答案3

几十年前,泰克公司Utek(基于 BSD 4.2 的 Unix,第一个在 National Semiconductors 上)32016CPU 然后是摩托罗拉68020s) 提供了一种称为 DFS(分布式文件系统)的东西,它//foo/bar指的是dfs 服务器/bar上的文件foo。它后来被 Sun 的 NFS 淘汰。

不幸的是,我还没有引用来支持这一点,但我最终可能会在我的地窖中找到一些 Utek 文档并更新此回复。

答案4

ReactOS项目 - NT 内核和相关 API 的免费开源实现 - 显然也承诺实现自己的英特克斯类似 POSIX 子系统(尽管 MS 最初的 OS/2 子系统也是上下文中提到的,没有提及 ReactOS 类似物)

尽管迄今为止的努力小的fork()显然是现实。这是子系统项目页面的摘录,如下所列开放式问题:

路径

在 POSIX 应用程序中使用 Win32 路径的最佳方法是什么?想法:

  • 翻译//<device>/<path> 成\\.\<device>\<path> (驱动器号有特殊情况 - //<letter>/<path>=> <letter>:\<path>- 和特殊转义符//./<raw text>=> \\.\<raw text>。可以使用 指定 UNC 路径//unc/<path>//路径由标准保留用于特定于实现的行为,并且//<letter>/转义 Win32 路径的语法广泛用于现有 POSIX 兼容性环境

  • 启发式识别“裸”Win32 路径

  • Win32 路径和//路径的不区分大小写的查找(标准是否允许这种特定于实现的//路径行为?)

我不确定这是否符合资格,因为我不确定其中有多少已经实施,但我认为这是对问题的有用有趣的描述。

相关内容