On Thu, Nov 29, 2018 at 3:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ... and after contemplating my navel for awhile more, I believe
> I understand the problem. APFS has sub-second file timestamp resolution,
> which doesn't seem to be exposed in Apple's version of "ls", but you can
> find it out from stat(2). And what I'm seeing is that "ranlib" is
> truncating the timestamp of its output file to a one-second boundary:
>
> $ ls -ltr
> ...
> -rw-r--r-- 1 tgl admin 25888 Nov 2 11:37 interval.c
> -rw-r--r-- 1 tgl admin 20692 Nov 2 11:37 timestamp.c
> -rw-r--r-- 1 tgl admin 210640 Nov 28 21:04 libpgtypes.a
> -rw-r--r-- 1 tgl admin 43232 Nov 28 21:04 numeric.o
> -rw-r--r-- 1 tgl admin 18688 Nov 28 21:04 datetime.o
> -rw-r--r-- 1 tgl admin 5916 Nov 28 21:04 common.o
> -rw-r--r-- 1 tgl admin 76584 Nov 28 21:04 dt_common.o
> ...
>
> $ ~/a.out numeric.o
> mtime - Actual: 1543457047.155932
> atime - Actual: 1543457047.651358
> $ ~/a.out libpgtypes.a
> mtime - Actual: 1543457047.000000
> atime - Actual: 1543457047.000000
Nice detective work. Possibly because libtool/ranlib whacks it with
utime(), which only knows about time_t, here:
https://github.com/opensource-apple/cctools/blob/master/misc/libtool.c#L2779
--
Thomas Munro
http://www.enterprisedb.com
