Static lib created with ar has timestamp with resolution 1 s

Question

I create a static lib from a single object file. The generated .a file has a timestamp with a resolution of one second (truncated to the earlier second), while the .o file does not.

In effect, it makes the .a file look like it is older than the .o file, and the lib is rebuilt the next time I make.

I hear there might be such problems om Mac, but I am using Ubuntu, x64.

In an attempt to understand what was going on, I made a simpler project to show the behavior. But in this case all is working as I expect:

gauthier@sobel:~/tmp/ar_test $ ls
hello.c  makefile
gauthier@sobel:~/tmp/ar_test $ make
gcc -c hello.c -o hello.o -g -Wall -Wextra -Werror -O3 -lrt
ar -cvq hello.a hello.o
a - hello.o
gauthier@sobel:~/tmp/ar_test $ ls --full-time
total 28
-rw-rw-r-- 1 gauthier gauthier 11940 2014-11-21 09:55:22.131715135 +0100 hello.a
-rw-rw-r-- 1 gauthier gauthier    81 2014-11-20 15:14:34.419613737 +0100 hello.c
-rw-rw-r-- 1 gauthier gauthier  5864 2014-11-21 09:55:22.131715135 +0100 hello.o
-rw-rw-r-- 1 gauthier gauthier   254 2014-11-20 15:17:47.533185970 +0100 makefile
gauthier@sobel:~/tmp/ar_test $ make
make: Nothing to be done for `all'.

There it's working, hello.a has a timestamp equal to that of hello.o.

Back to my original project. I can't find out what is different, but the timestamp for the lib is filled with zeroes after the seconds:

gauthier@sobel:~/code/myproj (master) $ ls
makefile  README.md  test  myproj.c  myproj.h
gauthier@sobel:~/code/myproj (master) $ make
gcc -c myproj.c -o myproj.o -g -Wall -Wextra -Werror -O3 -lrt -pthread
ar -cvqU libmyproj.a myproj.o
a - myproj.o
gauthier@sobel:~/code/myproj (master) $ ls --full-time
total 64
-rw-rw-r-- 1 gauthier gauthier 18852 2014-11-21 10:03:59.000000000 +0100 libmyproj.a
-rw-rw-r-- 1 gauthier gauthier  1363 2014-11-21 09:53:09.397383831 +0100 makefile
-rw-rw-r-- 1 gauthier gauthier   106 2014-11-20 13:49:15.299969786 +0100 README.md
drwxrwxr-x 2 gauthier gauthier  4096 2014-11-20 13:49:15.303969736 +0100 test
-rw-rw-r-- 1 gauthier gauthier  4741 2014-11-20 13:49:15.303969736 +0100 myproj.c
-rw-rw-r-- 1 gauthier gauthier  3584 2014-11-20 15:05:10.554702000 +0100 myproj.h
-rw-rw-r-- 1 gauthier gauthier 18648 2014-11-21 10:03:59.861206394 +0100 myproj.o
gauthier@sobel:~/code/myproj (master) $ make
ar -cvqU libmyproj.a myproj.o
a - myproj.o

Note here the timestamp of libmyproj.a: 10:03:59.000000000.

I have tried both options -U and -D to ar, to no av (not that I really though it should make a difference).

After further investigation, it looks like the problem depends on which directory the files are placed in:

• If I copy ~/code/myproj/myproj.o to the location of the test dir ~/tmp/ar_test/myproj.o, and run ar -cvq libmyproj.a myproj.o there, the timestamp is correct.

• If I copy ~/tmp/ar_test/hello.o to the location of the original project ~/code/myproj/hello.o and run ar -cvq libhello.a hello.o there, the timestamp is incorrect.

In other words: ar generates truncated timestamps when I am in ~/code/myproj, but not when I am in ~/tmp/ar_test.

What can make the lib lose the lower part of the timestamp, depending on which directory I am in?

Answer 1

Thanks to @Axel, problem solved. I'm writing the solution here, and hope it can save someone else googling their way here.

~/code (where the timestamps were truncated) was a filesystem of type fuse.encfs. Somehow, ar seems to fail to create a complete timestamp in this type of filesystem. This is strange, since the other files get the correct timestamps (gcc generates whole timestamps for object files, for example).

My solution was to work in an ext4 fs, and deal with encryption (which is the point of encfs) another way.