bug#7325: new test failure due to non-portability of printf formats like %05.3s

[Jim Meyering]

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?