Re: cp(1) fails to copy file from /proc

[James Youngman]

On Sun, Apr 19, 2009 at 1:52 PM, Jim Meyering <address@hidden> wrote:
> Andreas Schwab wrote:
>> Jim Meyering <address@hidden> writes:
>>
>>> Sure, but that's not the question.
>>> The question is whether we can assume short-read-on-regular-file
>>> implies EOF.
>>
>> I think you can look at it as if you are reading a growing file.
>
> Makes sense.
> But if a regular file is growing, then it's stat.st_size changes.
> For files in /proc, stat.st_size is always 0.
>
> If it is implemented that way, then it would be better
> to hide such counter-intuitive details from applications.
>
> Already, the fact that st_size is 0 for a known- and usually
> constant-sized, non-empty file is misleading -- probably contrary
> to POSIX, too, given the definition of st_size for a regular file.
>
> I wonder what would break if those types were changed from S_IFREG
> to S_IFIFO.  One drawback might be that files in /proc are currently
> seekable.  FIFO's aren't.
>
> It's a good thing that so few of the files in /proc are large
> enough to be affected.

I guess this doesn't help solve the general problem of reading /proc
files under arbitrary kernel versions, but I do find the standard of
implementation of /proc files to be low. at least in some kernel
versions; st_nlinks is also often wrong on directories, as well.   I
guess the problem sot st_size is that the code can't easily figure out
how much data it will produce without actually generating it; maybe it
would be efficient enough to make an overestimate (and perhaps pad the
result with newlines).

James.