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

[Paul Eggert]

On 11/08/10 08:02, Eric Blake wrote:
> In fact, since Paul originally wrote utimecmp.c, I'm surprised that you
> rewrote the coreutils hash table from scratch rather than trying to
> reuse the code.

I had vaguely remembered the issue, but I had forgotten where I put
that code.  utimecmp.c modifies the time stamp of the files, right?
So it might not be a good idea here.  But perhaps some of the common
code could be factored out.

Getting back to the point: I don't see a problem with 'stat' backward 
compatibility.
The guessed-resolution time stamps are output only if someone uses "%.X",
which is a format that nobody would use before the change.  So old
scripts shouldn't be broken by the change.

So it sounds like the issue is mostly about new scripts.  But for
those, we can tell people not to use "%.X" if they want to do textual
comparison.  Advice along these lines will be needed no matter what,
because, even if we could determine timestamp resolution perfectly,
there would still be a problem with blind use of "%.X".  Suppose someone
did something like this:

        ts=$(stat -c %.Y $old)
        cp -p $old $new
        # Wait for $new to be modified
        while [ $ts = $(stat -c %.Y $new) ]; do sleep .1; done

This won't work as desired even if stat could deduce timestamp resolution
perfectly, because $old and $new could be on different file systems,
and $new's file system could have a coarser resolution than $old's.

I can write a documentation patch along these lines if you like.