[
https://issues.apache.org/jira/browse/TS-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549353#comment-13549353
]
James Peach commented on TS-1645:
---------------------------------
I don't have any issues with the concept, but this breaks the build on OS X. It
would be best to add the autoconf checks for the struct stat nanosec field,
then wrap up the actual usage in a function.
> increase the file stat resolution
> ---------------------------------
>
> Key: TS-1645
> URL: https://issues.apache.org/jira/browse/TS-1645
> Project: Traffic Server
> Issue Type: Bug
> Components: Management
> Reporter: Yakov Kopel
> Attachments: stat_1.diff
>
>
> today the check of "file has been changed" is done by "stat" with resolution
> of seconds.
> I'm adding a patch to increase the resolution to neno-seconds. this is
> supported in part of file systems and kernels, but done no harm to others
> (the nanoseconds just be 0).
> from the man page:
> Since kernel 2.5.48, the stat structure supports nanosecond resolution for
> the three file timestamp fields. Glibc exposes the nanosecond component of
> each field using names of the form st_atim.tv_nsec if the _BSD_SOURCE or
> _SVID_SOURCE feature test macro is defined. These fields are specified in
> POSIX.1-2008, and, starting with version 2.12, glibc also exposes these field
> names if _POSIX_C_SOURCE is defined with the value 200809L or greater, or
> _XOPEN_SOURCE is defined with the value 700 or greater. If none of the
> aforementioned macros are defined, then the nanosecond values are exposed
> with names of the form st_atimensec. On file systems that do not support
> subsecond timestamps, the nanosecond fields are returned with the value 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
