On 3/6/07, Paul Eggert <[EMAIL PROTECTED]> wrote:
"James Youngman" <[EMAIL PROTECTED]> writes:
> I see that FreeBSD and NetBSD support st_birthtime. I'm considering
> supporting these in findutils. Is there any interest in suporting
> (i.e. maintaining if I contribute a patch) this in stat-time.h?
Sure, might as well.
Do they support st_birthtime with only a 1-second resolution, or
is it really a nanosecond resolution in the header?
Nanosecond resolution, I'm 99% sure. From sys/kern/vfs_vnops.c, we have
sb->st_size = vap->va_size;
sb->st_atimespec = vap->va_atime;
sb->st_mtimespec = vap->va_mtime;
sb->st_ctimespec = vap->va_ctime;
sb->st_birthtimespec = vap->va_birthtime;
(this is from
http://www.google.com/codesearch?hl=en&q=+package:freebsd+st_birthtime+show:2ytCzxabJn0:ORhCMuI2UCY:QS4ipTnTSvA&sa=N&cd=7&ct=rc&cs_p=http://gentoo.osuosl.org/distfiles/freebsd-sources-5.3.20050301.tar.bz2&cs_f=sys/kern/vfs_vnops.c#a0)
... so there's a struct timespec in there. Of course the ns field
could be permanently zero, but it is there (and hence I think we
should use it).
> If there is interest in maintaining the feature, how should we handle
> systems (like Linux) where this is not supported? By having the
> caller of stat-stime.h inline functions check
> HAVE_STRUCT_STAT_ST_BIRTHTIME itself?
That would be easiest to implement, I guess. It doesn't make much
sense to have a substitute value on platforms where st_birthtime was
not available, so the caller would need to decide what to do.
Agree. If we're running on a system without st_birthtime, there is
no way to fake knowing the missing information. So for findutils, if
the field is available in struct stat, several new tests (and printf
specifiers) will work. Otherwise, using those tests will cause a
fatal diagnostic at parse time.
James.
