yeah, thanks. On Sun, Aug 28, 2016 at 11:48 PM, 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
