boost::filesystem::canonical(const path& p) 的文档指出:



这样的结果是,如果p标识了目标不存在的符号链接(symbolic link),则该函数将以file not found失败,并且不会返回路径。

这对我来说似乎太过严格了:仅仅因为链接的目标不存在,我看不出函数无法解析该不存在的目标的路径的原因。 (相比之下,absolute()没有施加这样的限制。)

(很明显,如果路径中的符号链接(symbolic link)断开,则无法解析目标路径。)

那么,对此限制有合理的理由吗?

即使有,创建没有此限制的函数变体也没有道理吗? (没有这种变体,获取路径需要容易出错的手动复制canonical()已经完成的工作的99%。)

我理解stat()lstat()之间存在的语义微妙之处同样适用于这种情况-这正是我认为该功能的变体同样合理的原因。

注意:这个问题同样适用于基于std::experimental::filesystemboost::filesystem库(n4100)。

编辑:

在@Jonathan Wakeley在下面提供了非常有学问的答案之后,我仍然留下了原始问题的实质,我将对其进行略微调整:

  • boost::filesystem::canonical()是否要求目标存在才存在根本的技术或逻辑原因?我的意思是说,目标的不存在是否会以某种方式使它无法解决规范形式的问题?
  • 如果不是,是否有任何技术或逻辑上的理由不建议提出功能的变化,而该变化仅不同于现有形式,因为它不需要目标存在?
  • 在将boost::filesystem转换为拟议的N4100 std::experimental::filesystem的过程中(据我所知是这样),对canonical()的这种限制是否经过适当考虑后才采用,还是只是从Boost定义中“落空”?

  • 编辑2:

    我注意到,Boost 1.60现在提供了weakly_canonical()函数:“返回符号链接(symbolic link)已解析的p并将结果规范化。返回:一条路径,该路径由在存在的p的前导元素组成的路径上调用canonical()函数的结果组成,如果存在的话,后跟不存在的p元素(如果有)。”

    编辑3:

    std::filesystem有关的More discussion of this

    最佳答案

    尝试weakly_canonical(),它不需要在Mac上存在路径

    09-10 04:01
    查看更多