I see that the working version does this:
5308896: 23069079: statx("random-file-10", 0x2FF226F8, 128, 011) = 0
whereas the nonworking version does this:
11141146: 27853047: statxat(-2, "random-file-10", 0x2FF226F8, 76, 01) = 0
Notice the "128" in the former and the "76" in the latter.
These are offsets into the 'struct stat' (or struct statx?) object.
They tell statx (or statxat) how many slots to fill in.
One possibility is that the "128" is for largefile mode (which is what
'tar' should be using; it lets you access files large than 2 GiB), and that the
'76' is for smallfile mode (which tar should not be using). If this guess
is right, fstatat has a bug in that even when it is invoked in largefile mode,
it turns around and calls statxat in smallfile mode; that might explain the
bug. Can you please look into this theory? What members are in struct stat
(or struct statx) and what are their types and offsets? You should be able to look starting
in /usr/include/sys/stat.h to find this out.
Also, can you find out what the "011" and "01" flags mean in the above calls?
They may also be related.
aix71-stat.h attached - I'm sorry - can't pretend to skills I don't have. I don't know how to read this and give you the answer you're looking for.
Can you try compiling the test program with the exact same compiler flags
that 'tar' is compiled with? That may well be relevant. I am suspicious
of the fact that the test program's truss output uses "76, 01" internally;
that suggests to me that it's running in smallfile mode, which may not expose
the bug.
CFLAGS as created by ./configure are just "-g".
Also, can you try my most recent test program
on the same file system that's causing you trouble with GNU tar?
This may be filesystem-specific.
Doing all the tests on the same system in the same /lppdir filesystem.
And can you send the (compressed) config.log file?
aix71-stat.h.gz