确定“stat()”返回的有效时间戳精度
我正在尝试确定软件中 struct stat
的 st_mtim.tv_nsec
字段对于特定目录/文件系统的有效精度。
有没有办法确定文件系统的修改时间精度(而不是库的“纳秒”精度或操作系统目录缓存精度)?
添加:对于一些背景信息,这是用于更新某些文件的工具。基本场景是:“如果第一组文件中的某个文件可能比第二组文件中的任何文件更新,则使用第一组文件来更新第二组文件”接下来是“如果第二组文件中的某个文件可能比第三组文件中的任何文件更新,则使用第二组文件来更新第三组文件”。
我遇到的问题是,第一次运行该工具时(修改第一组中的文件后),它将更新第二组文件,然后更新第三组文件(这是正确的行为);但第二次运行该工具时(当没有任何更改时),第二组文件和第三组文件将具有相同的时间戳,因此它必须假设第三组中的文件可能更新,并且它会更新第三组文件无缘无故。
为了解决最初的问题,我在更新第三组文件之前引入了延迟(“nanosleep();”);因此,下次运行该工具时,第三组文件会稍微旧一些。这确实避免了不必要的更新。
当然事情没那么简单——有任意数量的相互依赖的“文件组”(不仅仅是 3 个组)。
这让我想到了我当前的问题 - 对于某些文件系统,时间戳精度高达 2 秒,并且“最坏情况”所需的延迟是巨大的(例如,对于 31 个级别的“”,它总计至少需要 60 秒的延迟)文件组”)。对于大多数文件系统来说,时间戳要精确得多,并且大量浪费的时间可能会消失。当然,该工具的目的是“尽可能便携”,并且我无法真正对时间戳精度做出任何假设(如果我知道文件系统始终是 ext4 或其他系统,那就很容易了) 。
I'm trying to determine the effective precision of the st_mtim.tv_nsec
field of struct stat
in software, for a specific directory/file system.
Is there a way to do it, that determines the file system's modification time precision (and not the library's "nanosecond" precision, or the OSs directory cache precision)?
ADDED: For some background information, this is for a tool that updates some files. The basic scenario is: "If a file in the first group of files could be newer than any file in the second group of files, then use the first group of files to update the second group of files" followed by "If a file in the second group of files could be newer than any file in the third group of files, then use the second group of files to update the third group of files".
The problem I'm having is that the first time the tool is run (after a file in the first group is modified) it'll update the second group of files and then update the third group of files (which is correct behaviour); but the second time the tool is run (when nothing has been changed) the second group of files and the third group of files will have the same timestamps so it has to assume a file in the third group could be newer and it'll update the third group of files for no reason.
To fix the initial problem I've introduced a delay ("nanosleep();") before updating the third group of files; so that the next time the tool is run the third group of files are slightly older. This does avoid the unnecessary updates.
Of course it's not that simple - there's an arbitrary number of "groups of files" that are inter-dependant (not just 3 groups).
That brings me to my current problem - for some file systems the time stamp precision is as bad as 2 seconds, and the "worst case" delay needed is huge (e.g. it adds up to at least 60 seconds of delays for 31 levels of "groups of files"). For most file systems the time stamps are much more precise, and the large amount of wasted time could disappear. Of course the tool is meant to be "as portable as possible" and I can't really make any assumptions about the time stamp precision (it'd be really easy if I knew the file system was always going to be ext4 or something).
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
根据此 OpenGroup 链接,
所以保证它至少是一秒。
另外,根据 stat(2) 上的 Linux 手册页:
According to this OpenGroup Link,
So you are guaranteed it to be at least one-second.
Also, according to this Linux man page on stat(2):
Linux 或 Windows 不是 RTOS(实时操作系统),这种类型的信息可能会延迟 100 毫秒,通常为 +-10 毫秒,因为我记得这是调度程序的标准时间片。
我不是最新的信息,但我很确定它仍然是这样工作的。
编辑
来自此处
Linux or Windows are not RTOS (real time operating systems) and that type of information can be off as bad as 100ms, typically +-10ms as I remember that was the standard time slice of the scheduler.
I am not up-to-date with that info, but I am pretty sure this is how it still works.
EDIT
From here
据我所知,这是不可能的。
唯一实际的解决方法是允许最终用户以适合他们的方式配置它。
注意:我自己尝试找出一种方法,并在此处和其他一些地方询问(主要是 C 和 POSIX 的 IRC 频道);没有人(包括我自己)能够找到一种方法来做到这一点。
As far as I know, it can't be done.
The only practical work-around is to allow the end user to configure it in a way that suits them.
Note: I tried to figure out a way myself, and asked here and a few other places (mostly IRC channels for C and POSIX); and nobody (including myself) have been able to find a way to do it.