What error does copy_file_range() give? On Sun, 28 Aug 2016 at 22:48, Michael Kerrisk (man-pages) <mtk.manpages@xxxxxxxxx> wrote: > > On 08/27/2016 05:47 AM, Ursache Vladimir wrote: > > Here's another issue, this time related to stat(), st_size and regular files. > > > > I think stat(2) should be updated in relation to exceptions with > > st_size and regular files. > > Currently the man pages describe this exception (corner case) as: > > > > "For most files under the /proc directory, stat() does not return the > > file size in the st_size > > field; instead the field is returned with the value 0." > > > > However, I found at /sys/devices/cpu/ and in other (Linux kernel) > > directories (all) regular files > > to report 4096 bytes yet their real size is only a few bytes (for > > example the regular > > file "/sys/devices/cpu/type" st_size=4096 bytes yet one can only read 2 bytes). > > > > Hence in some cases (st_size=0) it reports a smaller size, and in the > > latter case - a bigger size > > (st_size=4096). > > > > I don't know if these cases are posix compliant and since you have a > > lot more experience I hope you'll > > write the proper explanation in place of the one mentioned at the top. > > I would write something > > like this: > > > > "Many regular files generated by the (Linux) kernel at /proc or /sys > > return an st_size that has nothing > > to do with the real file size so one should try to read as much as one > > can and append > > a '\0' at the end if it's a text file"; > > > > But then the regular file at /proc/kcore reports st_size=many terabytes. > > So, it's not going to be possible to explain every corner case here, but > text such as you suggest is good to alert the programmer. Starting from > your suggestion, I reworked this to: > > For many pseudofiles that are autogenerated by the kernel, stat() > does not return an accurate value in the st_size field. For exam‐ > ple, the value 0 is returned for many files under the /proc direc‐ > tory, while various files under /sys report a size of 4096 bytes, > even though the file content is smaller. For such files, one > should simply try to read as many bytes as possible (and append > '\0' to the returned buffer if it is to be interpreted as a > string). > > Okay? > > Cheers, > > Michael > > -- > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > Linux/UNIX System Programming Training: http://man7.org/training/ -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
