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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
