C 线程文件系统操作：到 ftw() 还是到 fts_open()？答案

【问题标题】：C threaded filesystem operations: to ftw() or to fts_open()?C 线程文件系统操作：到 ftw() 还是到 fts_open()？
【发布时间】：2018-11-03 05:28:50
【问题描述】：

假设一个线程程序正在执行文件系统操作（遍历、读取、创建、删除、移动目录和文件）。

根据an answer，ftw() 在这种情况下是不安全的。（另外，ftw() 需要全局变量，这似乎不太优雅。）

我应该改用fts_open() / fts_children() / fts_read() 吗？或者scandir()？

线程程序使用ftw()（其中某个线程正在使用ftw() 聚合数据，而另一个线程正在删除/移动某些数据）的不安全之处是什么？为什么？

【问题讨论】：

如果一个线程执行chdir()，而另一个线程正在执行ftw()，所有的地狱都可能崩溃。在扫描目录时删除它也可能会导致问题（但这可能发生在另一个进程中，更不用说其他线程了）。便携性是个问题吗？它可能并非随处可用（BSD/macOS 将其标记为“预计将包含在未来的 IEEE Std 1003.1-1988 ('POSIX.1') 修订版中”，这提高了它的便携性，但不能保证它— 它不在 POSIX 2018 中。
如果您在线程应用程序中，您可能需要使用FTS_NOCHDIR，或者谨慎使用*at() 函数来访问文件。
便携性不是问题。那么，改变进程的工作目录（来自不同的线程）是唯一会导致不一致的事情吗？绝对路径是魔术修复吗？ FTS_NOCHDIR 能保证解决这个问题吗？我真的很难理解可能出现的问题......！
我不知道改变目录是否是遇到问题的唯一方法；这只是事情可能被搞砸的一种相当重要的方式。如果您有两个线程或两个进程在工作，一个尝试通过fts_read() 等扫描文件系统，另一个进行任意更改（例如将目录从树中的一个位置移动到另一个位置），那么我可以通过扫描代码在会计中看到各种混淆的机会 - 忽略应该计算的东西，计算两次应该只计算一次的东西。
我要提到nftw()，因为它还没有出现，它比ftw() 有几个优点，但线程安全不是其中之一。因此，这主要是因为困扰fts_read()和ftw()的问题也困扰nftw()。

标签： c file unix directory filesystems

【解决方案1】：

^{将 cmets 转换为答案。}

如果一个线程执行chdir() 而另一个线程正在执行ftw()（或nftw()），所有的地狱都可能会崩溃。在扫描目录时删除它也可能会导致问题（但这可能发生在另一个进程中，更不用说其他线程了）。

便携性是个问题吗？ fts(3) 功能套件可能并非随处可用（BSD/macOS 将其标记为“预计将包含在未来的 IEEE Std 1003.1-1988 ('POSIX.1') 修订版中”，这提高了其便携性的机会，但不能保证——它不在 POSIX 2018 中^{（见下文）}。

如果您在线程应用程序中，您可能需要使用FTS_NOCHDIR，或者谨慎使用*at() 函数来访问文件。

便携性不是问题。那么，改变进程的工作目录（来自不同的线程）是唯一会导致不一致的事情吗？绝对路径是魔术修复吗？ FTS_NOCHDIR 能保证解决这个问题吗？

我不知道更改目录是否是遇到问题的唯一方法；这只是事情可能被搞砸的一种相当重要的方式。如果您有两个线程或两个进程在工作，一个尝试通过fts_read() 等扫描文件系统，另一个进行任意更改（例如将目录从树中的一个位置移动到另一个位置），那么我可以看到扫描代码所做的会计中的各种混淆机会 - 忽略应该计算的东西，计算两次应该只计算一次的东西。

我要提到nftw()，因为它还没有出现。与ftw() 相比，它有几个优点，但线程安全不是其中之一。因此，这主要是因为困扰fts_read()和ftw()的问题也困扰着nftw()。

注意scandir() 读取并选择单个目录的内容而不遍历层次结构。它是为ftw() 和朋友的不同工作而设计的。它不是 ftw() 等人的简单替代品。

看起来 fts(3) 已被考虑但因 POSIX 被拒绝：http://www.opengroup.org/platform/ballots/1003.1a.d14.crb.txt

【讨论】：