James Youngman wrote:
> On Thu, Apr 16, 2009 at 1:54 PM, Jim Meyering <[email protected]> wrote:
>> Thank you for the bug report.
>> The relevant code from coreutils/src/copy.c is here:
>>
>> /* A short read on a regular file means EOF. */
>> if (n_read != buf_size && S_ISREG (src_open_sb.st_mode))
>> break;
>>
>> That optimization was added over three years ago, with this change:
>>
>> http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=25719a33154f0c6
>>
>> It appears that it is not (no longer?) valid for most mainstream kernels,
>> at least for files on /proc, so I'll remove it or adjust it.
>
> Really? This seems more like a kernel bug to me. Specifically, I
> was under the firm impression that a short read from a file _does_
> mean that you've reached the end-of-file.
Here's what POSIX's read description says about that:
The value returned may be less than nbyte if the number of bytes left
in the file is less than nbyte, if the read( ) request was interrupted
by a signal, or if the file is a pipe or FIFO or special file and has
fewer than nbyte bytes immediately available for reading. For example,
a read( ) from a file associated with a terminal may return one typed
line of data. If a read( ) is interrupted by a signal before it reads
any data, it shall return -1 with errno set to
Perhaps it comes down to the definition of "special file".
These files are obviously special, but perhaps not in the
letter-of-POSIX sense.
Even if it is a kernel bug, most linux-kernel users will still
have to skip the optimization for a long time.
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
