我正在尝试确定软件中st_mtim.tv_nsec struct stat字段对于特定目录/文件系统的有效精度。
有没有办法做到这一点，这决定了文件系统的修改时间精度（而不是库的“纳秒”精度，或OSs目录缓存精度）？
增加：对于某些背景信息，这适用于更新某些文件的工具。基本方案是：“如果第一组文件中的文件可能比第二组文件中的任何文件更新，则使用第一组文件更新第二组文件”然后是“如果第二组文件中的文件可能比第三组文件中的任何文件更新，则使用第二组文件更新第三组文件”。
我遇到的问题是第一次运行该工具（在第一组文件被修改后），它将更新第二组文件，然后更新第三组文件（这是正确的）行为）;但第二次运行该工具（当没有任何更改）时，第二组文件和第三组文件将具有相同的时间戳，因此它必须假定第三组中的文件可能更新并且它将更新第三组文件无缘无故。
为了解决最初的问题，我在更新第三组文件之前引入了延迟（“nanosleep（）;”）;这样，下次运行该工具时，第三组文件会稍微过时。这确实避免了不必要的更新。
当然不是那么简单 - 有任意数量的“文件组”是相互依赖的（不只是3组）。
这让我想到了我当前的问题 - 对于某些文件系统，时间戳精度低至2秒，并且所需的“最坏情况”延迟很大（例如，它累计延迟至少60秒） “文件组”的级别。对于大多数文件系统，时间戳更加精确，浪费的大量时间可能会消失。当然这个工具意味着“尽可能便携”，我无法对时间戳精度做出任何假设（如果我知道文件系统总是会是ext4之类的东西，那真的很容易）
答案 0 :(得分：3)
根据此OpenGroup Link，
文件系统中文件的时间戳分辨率为 实施定义，但不比一秒更粗糙 解析度。三个时间戳应始终具有值 由文件系统支持。每当文件的任何时间戳都是 根据前面的规则设置为值V. 本节段落的实施应立即设定 时间戳到文件系统支持的最大值 不大于V.
所以你保证它至少有一秒钟。
另外，根据stat(2)上的这个Linux手册页：
从内核2.5.48开始，stat结构支持纳秒分辨率 对于三个文件时间戳字段。
答案 1 :(得分：2)
Linux或Windows不是RTOS（实时操作系统），而且这种类型的信息可以关闭到100毫秒，通常是-10毫秒，因为我记得这是调度程序的标准时间片。
我不了解这些信息，但我很确定这是它仍然有效的方式。
编辑
nanosleep（）的当前实现基于正常 内核定时器机制，其分辨率为1 / HZ s（参见 时间（7））。因此，nanosleep（）暂停至少 指定的时间，但它可能比指定的时间长达10毫秒 直到该过程再次可运行。出于同样的原因， 通常在* rem中传送信号时返回的值 四舍五入为1 / HZ的下一个较大倍数。
来自here
答案 2 :(得分：1)
据我所知，无法做到。
唯一可行的解决方法是允许最终用户以适合他们的方式对其进行配置。
注意：我试图找出一种方法，并在这里和其他一些地方（主要是C和POSIX的IRC频道）询问;没有人（包括我自己）能够找到办法。