C 线程文件系统操作 : to ftw() or to fts_open()?

Question

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

根据 an answer , ftw() 在这种情况下是不安全的。 (此外，ftw() 需要全局变量，这看起来不太优雅。)

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

使用 ftw() 的线程程序有什么不安全的(其中一些线程正在使用 ftw() 来聚合数据，而另一个线程正在删除/移动一些数据)，确切地说，为什么？

Answer 1

^{将评论转化为答案。}

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

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

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

Portability is not an issue. So, changing the working directory of the process (from different threads) is the only thing that can lead to inconsistencies? Are absolute paths a magic fix? Is FTS_NOCHDIR guaranteed to solve this issue?

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

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

请注意 scandir()在不遍历层次结构的情况下读取和选择单个目录的内容。它是为与 ftw() 和 friend 不同的工作而设计的。它不是 ftw() 等的简单替代品。

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