bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st_birthtime


From: James Youngman
Subject: Re: st_birthtime
Date: Tue, 6 Mar 2007 09:34:53 +0000

On 3/6/07, Paul Eggert <address@hidden> wrote:
"James Youngman" <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]