Re: nanosecond file timestamp resolution in filesystems, GNU make, etc.

[Jamie Lokier]

Andi Kleen wrote:
> > So I propose: add a field to struct stat indicating the resolution of
> > the timestamps in it.  It can go on the end.
> It's impossible. There is no space left in struct stat64
> And adding a new syscall just for that would be severe overkill.

There's the 4 bytes following dev_t in Glibc's definition (call __pad1
in Glibc) which isn't used by Glibc or anything else.  That's still
free even when the kernel changes to 64-bit dev_t.

And if you don't like that to do that, i.e you want to guarantee that
the unused word continues to be zero for older programs (though I
can't think of any reason why it would matter), that's what the
(currently unused) flags argument to stat64() is for.

> But what you could do if you really wanted that: implement kernel
> POSIX pathconf()/fpathconf() and implement it as a parameter to
> that.

Ugh.

> I personally have no plans to implement it [pathconf], however,
> because it looks like kernel bloat to me :-)

Given the choice of using fpathconf, I'd rather accept that the
nanoseconds field is not reliable, hence I must ignore it.  It does
seem a waste though - sometimes you are returning good information I
can use, other times you're not, and I can't tell the difference :-(

I'd much rather do this right.  What do you think of storing the
resolution in the unused word called __pad1 in Glibc?

(Btw, it wouldn't bloat the in-core kernel inode, because only a
couple of flag bits are needed there to distinguish known resolution
values).

-- Jamie