Re: signal-handling problems for "dd": some thoughts

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
...
>>> However, I don't see any way of implementing it reliably for slow
>>> devices....
>>
>> Why not?
>> Because we can't rely on signal semantics to defer signals
>> while in the critical read or write sections?
>
> Yes, that's right.  We can't block signals while reading (because
> then, the read might hang and we might ignore signals indefinitely),
> and we can't not block them either (because they might interrupt the
> read, and this messes up dd's block boundaries).

But for progress reporting, don't we need to block only
one signal (SIGUSR1) while e.g., reading?  Of course, that'd mean no
progress reporting during a read, but that doesn't seem too restrictive.

> "dd" is perhaps a special case because it really cares about short
> reads.
>
> It might be possible to work around this by using "select" before each
> read and/or write; also by having multithreaded apps.  Both of these
> are kind of heavyweight options, though, and I suspect they'll suffer
> from their fair share of porting bugs.
>
>> The ideal would be to find an approach that avoids adding a new option
>> to each tool that supports a progress bar.
>
> I suppose it could be an environment variable, listing the
> progress-bar options.  But how many coreutils programs are we talking
> about here?  If it's just cp and dd it might be simpler just to add
> options.

Whatever approach we use, shred certainly deserves the same treatment
Other possible candidates: install, and maybe mv, if we care about when
it has to resort to copying, but I don't think it's worthwhile to change
them.

As for dd's feature, I liked the idea of being able to decide,
after starting a transfer, to enable some sort of progress-reporting mode.
Sometimes, it seems like it's taking too long and/or one can't easily tell
that it's making progress.