Determine effective timestamp precision returned by "stat()"

Question

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).

Answer 1

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.

Answer 2

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

The current implementation of nanosleep() is based on the normal kernel timer mechanism, which has a resolution of 1/HZ s (see time(7)). Therefore, nanosleep() pauses always for at least the specified time, however it can take up to 10 ms longer than specified until the process becomes runnable again. For the same reason, the value returned in case of a delivered signal in *rem is usually rounded to the next larger multiple of 1/HZ s.

From here

Answer 3

According to this OpenGroup Link,

The resolution of timestamps of files in a file system is implementation-defined, but shall be no coarser than one-second resolution. The three timestamps shall always have values that are supported by the file system. Whenever any of a file's timestamps are to be set to a value V according to the rules of the preceding paragraphs of this section, the implementation shall immediately set the timestamp to the greatest value supported by the file system that is not greater than V.

So you are guaranteed it to be at least one-second.

Also, according to this Linux man page on stat(2):

Since kernel 2.5.48, the stat structure supports nanosecond resolution for the three file timestamp fields.