Originally found as additional minor bug in ticket #51345 (Knoppix 9.1 with
GNU Coreutils 8.32), I think it is a good idea to create a dedicated report
for it to avoid getting it lost.
When dd is being used with status=progress it appears to update the status
every second but does not do a final
On 28/10/2021 22:59, Sworddragon wrote:
Despite I'm not using Linux as main system anymore and wanted to avoid
getting into too much work I found some time to do some tests as this issue
bugs me just too much.
You could try running the following immediately after,
to see if it also returns
I got an email that somebody replied to this report but it looks like they
did send it to the wrong mail address (maybe they will be merged in order)
but I will still reply to it:
> Suggestion as a possible workaround: Have a look at random(4) and
random(7),
> and ask yourself whether your use of
On 28/10/2021 22:59, Sworddragon wrote:
Despite I'm not using Linux as main system anymore and wanted to avoid
getting into too much work I found some time to do some tests as this issue
bugs me just too much.
You could try running the following immediately after,
to see if it also returns
On 10/29/21 05:38, Pádraig Brady wrote:
I'm leaning towards improving this by always
doing an fsync on exit if we get a read or write error
and have successfully written any data, so that
previously written data is sync'd as requested.
Sounds like a good idea to me too.
On 10/28/21 12:11, Paul Eggert wrote:
Wait - lseek returns a number less than -1?! We could easily check for
that FreeBSD bug, perhaps as an independent patch; this shouldn't
require any extra syscalls.
I installed the attached patch to do this. This doesn't fix coreutils
bug#51433; it
On 10/28/21 13:59, Pádraig Brady wrote:
I wonder after getting a SEEK_DATA ENXIO, might we correlate
we really are at end of file by checking SEEK_HOLE also returns ENXIO?
Wouldn't SEEK_HOLE return the current offset, instead of ENXIO? That is,
if the underlying data structure is wrong and
