Re: [Bug-tar] Tar short read

[Kevin Fox]

On Tue, 2011-09-27 at 08:23 -0700, Fox, Kevin M wrote:
> On Mon, 2011-09-26 at 18:08 -0700, Paul Eggert wrote:
> > On 09/26/11 17:40, Kevin Fox wrote:
> > > But, an hypothetical question, if I simply sent out a signal in the file
> > > system while issuing the partial read
> > 
> > Sorry, that wouldn't fix things; applications like 'tar' would exit.
> 
> What about SIGSTOP/SIGCONT? I don't believe they can avoid those.

Some more info here:

http://www.gnu.org/s/hello/manual/libc/I_002fO-Primitives.html

GNU libc states:
The return value is the number of bytes actually read. This might be
less than size; for example, if there aren't that many bytes left in the
file or if there aren't that many bytes immediately available. The exact
behavior depends on what kind of file it is. Note that reading less than
size bytes is not an error.

And:
"If read returns at least one character, there is no way you can tell
whether end-of-file was reached". But if you did reach the end, the next
read will return zero.

So assuming you don't need to read again for a partial read is
considered bad behavior by the glibc guys.

They are not specific as to what causes a partial read. Digging deeper,
under EINTR it has this link:

http://www.gnu.org/s/hello/manual/libc/Interrupted-Primitives.html#Interrupted-Primitives

There is this tidbit:

There is one situation where resumption never happens no matter which
choice you make: when a data-transfer function such as read or write is
interrupted by a signal after transferring part of the data. In this
case, the function returns the number of bytes already transferred,
indicating partial success.

I can't see any way that a program receiving a signal like SIGCONT
during a partial read and it not properly handling the partial read
response would not be considered a bug. Yes, it may be a common bug, but
a bug none the less.

If that is the case, all programs using read need to assume a signal can
come in any time and a partial read is normal. Since a program has no
way of knowing a partial read with signal from a partial read with no
signal, so then that explains the glibc stance of a partial read is
always to be expected, signal or no and to program defensively against
it.

Thanks,
Kevin

> 
> Kevin
> 
> 
>