boost::filesystem::canonical(const path& p)
的文档指出:
这样的结果是,如果p标识了目标不存在的符号链接(symbolic link),则该函数将以file not found
失败,并且不会返回路径。
这对我来说似乎太过严格了:仅仅因为链接的目标不存在,我看不出函数无法解析该不存在的目标的路径的原因。 (相比之下,absolute()
没有施加这样的限制。)
(很明显,如果路径中的符号链接(symbolic link)断开,则无法解析目标路径。)
那么,对此限制有合理的理由吗?
即使有,创建没有此限制的函数变体也没有道理吗? (没有这种变体,获取路径需要容易出错的手动复制canonical()
已经完成的工作的99%。)
我理解stat()
和lstat()
之间存在的语义微妙之处同样适用于这种情况-这正是我认为该功能的变体同样合理的原因。
注意:这个问题同样适用于基于std::experimental::filesystem
的boost::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上存在路径