Garrett D'Amore wrote: > Don Cragun wrote: > > On Fri, 21 Aug 2009 00:00:53 -0700, Hugh McIntyre wrote: > >> Joerg Schilling wrote: > >>>>>>>> int futimens(int fd, const struct timespec times[2]); > >>>>>>>> > >>>>>>>> int utimensat(int fd, const char *path, > >>>>>>>> const struct timespec times[2], int flag); > >>>>>>>> > >>>> In order to allow programs like star to be able to work correctly, we > >>>> would > >>>> also need to have a pathconf()/fpathconf() call to retrieve the _actual_ > >>>> resolution of a filesystem. > >>>> > >> It looks like there's already a standard for this (perhaps just > >> proposed?): _POSIX_TIMESTAMP_RESOLUTION and _PC_TIMESTAMP_RESOLUTION. > > > > These are not just proposed; tHey were added to the standards at the > > same time futimens() and utimensat() were added. > > > > I believe this project is incomplete without also adding support for > > these to the fpathconf() and pathconf() functions and the getconf > > utility. > > Hm.... it seems that these should definitely be added. I'm happy for > them to be added to this project, but I'm not sure it is *required*.
I think it is required since otherwise there is no good way to know why the timestamp changed between "set" and "get" ... > Indeed, the pathconf/fpathconf changes should probably have been made at > the time ZFS introduced nanosecond resolution. Doesn't tmpfs have nanosecond resolution since a long time ? > So while there is a relationship here, I'm not sure that the projects > are necessarily locked together. I think these are indirectly locked together and this issue needs to be fixed - otherwise there's no way to use the proposed API correctly for some applications. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
