Paul Eggert <[email protected]> writes:
> On 2026-06-19 00:54, Paul Eggert wrote:
>> from dd's point of view, it asked for the time and got the wrong
>> time from the kernel.
>
> On looking into this a bit more, my guess is that the underlying
> kernel and/or firmware bug is not likely to be fixed any time soon, so
> I installed the attached workaround to coreutils. Please give it a
> try.
I don't think this is the cause. I changed 'dd' to use a monotonic clock
with this commit:
commit c3eb8b45798133dba06defd72f6280fd1ce3fcd3
Author: Collin Funk <[email protected]>
AuthorDate: Sat Dec 6 17:19:55 2025 -0800
Commit: Collin Funk <[email protected]>
CommitDate: Sun Dec 7 11:37:17 2025 -0800
shred: use gethrxtime instead of time
The gethrxtime function uses a monotonic clock if available on the
system. The effect should be unnoticeable since we print --verbose
information every 5 seconds, but is more correct and we already do the
same in 'dd'.
* src/local.mk (src_shred_LDADD): Add $(GETHRXTIME_LIB).
* src/shred.c (dopass): Use xtime_t instead of time_t. Use gethrxtime
instead of time.
The original reporter is using coreutils-9.7, which did not contain this
commit:
$ git tag --contains=c3eb8b45798133dba06defd72f6280fd1ce3fcd3 \
| sort --version-sort | head -n 1
v9.10
Unless a distribution picked up that patch, which I would find
surprising, his version uses gettimeofday.
Collin
