Re: readlink() example sometimes fails

["Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html