Dear Maintainer,

In Trixie, dd status=progress doesn't ever print status like it used to.

For instance, I'm testing this with
    dd if=bigfile.img of=/dev/null status=progress

But it also happens when of is an SD card or other slow device, so this isn't just an issue of /dev/null being fast.

On my system, the reason progress isn't shown is that in line 2181 of dd.c:
          if (next_time <= progress_time)
one or both of these numbers is frequently negative, and at least on my system, next_time is almost always greater than progress_time. So print_xfer_stats() is never called.

This also means that next_time hardly ever gets incremented, because it only gets incremented in the case where it's <= progress_time, which is almost never true.

I'm not sure why it's going by time anyway; shouldn't it go by bytes copied?

If I change the line to
          if (1 || next_time <= progress_time)
then I do see a progress indication. But obviously this isn't the best solution.

next_time and progress_time are type xtime_t, defined in lib/xtime.h as:

typedef long long int xtime_t;

Shouldn't they be declared as something unsigned, so they can't overflow and go negative?

I wondered if that was the ultimate source of the problem, but I tried redefininxtime_t as unsigned long long and it didn't fix the problem; next_time was still usually greater than progress_time so next_time never got updated and print_xfer_stats still never got called.

Some people apparently see progress, other people don't (a web search found lots of people complaining about status=progress not working). I'm not sure what the difference is, but I never see any progress indicators on my system (a fairly vanilla x86_64-based Lenovo Carbon X1). Maybe some systems have a longer "long long" than I do, for whatever reason?