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. 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. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
