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

[Jim Meyering]

Mike Frysinger wrote:

> On Saturday 18 April 2009 16:58:52 Jim Meyering wrote:
>> Mike Frysinger wrote:
>> > On Friday 17 April 2009 18:28:07 James Youngman wrote:
>> >> The patch itself looks good, but it might be worth leaving in a
>> >> comment indicating why the optimisation should not be reintroduced...
>> >
>> > and/or a new test (i prefer the "and"):
>> >  if [ -e /proc/cpuinfo ] ; then
>> >    cp /proc/cpuinfo cpuinfo.cp
>> >    cat /proc/cpuinfo > cpuinfo.cat
>> >    cmp cpuinfo.cp cpuinfo.cat
>> >  fi
>>
>> Of course ;-)
>> As promised, I've added a test for this below.
>>
>> We can't use /proc/cpuinfo, at least not precisely like that,
>> because its cpu speed line can change due to frequency scaling.
>> Also, that file is usually too small to trigger the failure.
>
> hmm, i seem to remember cpuinfo being a pita when doing remote `ssh cp ...`,
> but must have been some other file.  you got the idea at any rate :).
>
>> Here's a more complete patch, with a title and NEWS reflecting
>> that I now think it's a linux kernel bug.
>
> i think that characterization is incorrect.  POSIX certainly states that a
> read value smaller than what was requested is not an error in and of itself.

Sure, but that's not the question.
The question is whether we can assume short-read-on-regular-file
implies EOF.

The spec does say when a short read "may" occur, and this case
(S_ISREG and no interrupt), is not one of them.  If the list of
cases in that "may" clause is intended to be complete, then I see
no other interpretation.

> i havent looked at the kernel internals as to why this occurs, but if i had to
> make a guess, it's related to the seq_file stuff as a common helper in place
> of many common buggy procfs implementations.  and in that case, the current
> behavior is to be expected.

Whether it's officially a kernel bug depends mainly on how we
interpret the POSIX spec for read.