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 > > >
