Re: cp(1) fails to copy file from /proc

[Jim Meyering]

James Youngman wrote:
> On Thu, Apr 16, 2009 at 1:54 PM, Jim Meyering <address@hidden> 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.