Re: size of files in /proc

Ton Hospel (thospel@mail.dma.be)
21 May 1998 12:39:12 GMT


In article <Pine.SUN.3.96.980520165338.4197A-100000@amsterdam.lcs.mit.edu>,
"C. Scott Ananian" <cananian@lcs.mit.edu> writes:
> On Tue, 19 May 1998 thospel@mail.dma.be (Ton Hospel) wrote:
>
>> But even then I'd like /proc to report the unknown sizes as 1, not 0.
>> Because I like to be able to export /proc over NFS, and NFS doesn't even
>> bother to read the file if the size is 0.
>>
>> A(nother) possibility is to cache the size from last time the file contents got
>> generated. For most files that should be in the right ballpark.
>
> This is exactly the Wrong Thing To Do. A file size of zero indicates that
> the file is special in some way. Trying to guess the "right" value and
> missing is Much Worse -- you're actually giving wrong information and
> creating situations where programs work "most of the time" -- except for
> that time when the guess is very wrong and everything breaks.
>
> NFS needs fixing, not /proc. A zero-sized file is the best way to say "I
> don't know."

We have no code for "special". If you want to indicate that, make the proc
entries e.g. named pipes (which I would strongly oppose by the way. I'd rather
go the way of making /proc behave more like real files).
Size 0 means "at that moment you did the stat, the file was empty"

Fixing NFS would be wrong here, since concluding the file is empty if the size
is zero is a VALID thing to do. It's the reporting of size 0 of /proc that's
wrong.

>
> [Note that silly mmap implementations of (for example) cp may have
> problems with zero-length files, as well. They would have the same
> troubles with 'finite but wrong' sized files, except the bugs would be
> much more subtle.]
> --Scott

These implementations of cp are RIGHT. And no, we wouldn't have that
problem with finite sized files, because you may NOT conclude that
if you asked the size and later really read it, it will still have that
size. Zero is special in that if you know the size, you know the full
contents, which is not true for any other number, in all other cases the
program HAS to read the contents to avoid a race.

I see this argument as another reason to fix /proc

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu