Pádraig Brady wrote: > On 12/11/10 11:22, Jim Meyering wrote: >> Pádraig Brady wrote: >>> On 11/11/10 17:54, Paul Eggert wrote: >> ... >>>> It's >>>> not a big deal, but I still mildly prefer the * notation. >> >> Same here. >> >> However, here's an argument for using a different method, perhaps >> with a hard-coded mapping from common FS types to known precision: >> >> Running these two commands with different ordering prints >> different results. When the file with NS%10 == 0 comes first, >> stat suppresses the trailing 0(s): >> >> $ stat -c '%4n %.*Z' 3 9 >> 3 1289555520.29981438 >> 9 1289555520.300814502 >> >> After the first non-multiple-of-10 nanoseconds value, >> stat prints all trailing 0's: >> >> $ stat -c '%4n %.*Z' 9 3 >> 9 1289555520.300814502 >> 3 1289555520.299814380 > > That's just a special case of: > find ... | xargs stat ... > So it's no worse that differences over multiple runs of stat IMHO > > As for the general question of using hard coded resolutions for FS types. > It might be OK as long as you err'd on the side of too big rather than too > small. > Though isn't everything going to tend towards nanoseconds going forward? > > This feature is starting to seem a bit like over engineering > for what it gives us TBH. If it was guaranteed to give us > an indication of the timestamp resolution, then OK > but otherwise I don't think it's worth it.
I agree. I'd like to defer the addition of this feature, at least until it's more predictable. Is that ok with you, Paul?
