"Roger A. Faulkner" <Roger.Faulkner at sun.com> wrote:
> > IIRC, then the pcfs timestamps have a 2 second timestamp granularity
> > for the mtime and a one day granularity for the atime.
> >
> > The latter cannot be represented in the pathconf() fcall.
> >
> > J?rg
>
> Yeah, well...
>
> I just made pathconf(_PC_TIMESTAMP_RESOLUTION) return 1000 000 000
> for pcfs. Is that good enough? Does anyone really care?
> Should I make it fail (-1 w/ EINVAL)?
Star and cpio decide on the timestamp whether a file will be extracted or not.
If pathconf(_PC_TIMESTAMP_RESOLUTION) returns 1000 000 000, star will probably
make a wrong decision in future because a timestamp of 1000 may be a rounded
down 1001. Star currently implements some heuristics but in case that
pathconf(_PC_TIMESTAMP_RESOLUTION) will work, future versions will asume that
the returned value is correct.
2 seconds may be represented by a 32 bit value.
BTW: POSIX requires pathconf(_PC_TIMESTAMP_RESOLUTION) to return -1/EOVERFLOW
in case of an number overflow. We would need to do this if we look at atime.
I however tend to believe it is better not to return an overflow as mtime is
more important than atime.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
