Re: size of files in /proc

Ton Hospel (
22 May 1998 15:47:57 GMT

In article <>,
Kevin Lentin <> writes:
> On Thu, May 21, 1998 at 12:39:12PM +0000, Ton Hospel wrote:
>> 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 don't get this bit. Why can't there be a race? File gets created, size 0.
> NFS stats. File gets written to. NFS says no data in file. EOF.

Valid behaviour. NFS sampled a file property (size), and since it's zero,
this also implies the file contents (empty).

> Comapred to:
> File has 100 bytes. NFS stats. File gets appended to. NFS reads and returns
> 200 bytes.

That's what NFS does, and is what I would expect from a program with
copy semantics.

Reading a file that can be changing always implies you
are doing a measurement ("taking a sample"). All you can expect from a copy
is that it returns a copy of the contents a file had somewhere during it's run.
(the behaviour of /proc is more that behind your back other files get put
under a certain name. In principle we don't want a proc file to change once
you did an open, since you could get very confusing results that way)

> Or does NFS only ever return as much data on a read as a previous stat said
> there was to read?

No, once NFS really opens the file, it in fact behaves fine.
That's indeed the race I was referring to, and NFS does not fall for it.

>> I see this argument as another reason to fix /proc
> But HOW, when you don't know the sizes of the files?
Simple, make the size anything but 0, even if that is just as inaccurate as
the 0 was. In that case programs MUST read the file in order to get it's
contents. Giving all proc files with unknown size 1 as length would work fine.
0 is unfortunate since it's the only case where size implies contents.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to