Re: size of files in /proc

C. Scott Ananian (
Fri, 22 May 1998 16:20:39 -0400 (EDT)

On Thu, 21 May 1998 (Ton Hospel) wrote:

[quoting drastically curtailed. For context, see the archives]
> "C. Scott Ananian" <> writes:
> > [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.]

> 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 think you're missing my point. If /proc gave bogus values for the size,
instead of 0, then programs that rely on the size would *irregularly,
erratically, and unpredictably* give wrong results, depending on the
relationship of the real size to the reported size. It is not sane to
generate true sizes for the /proc files (we'd have to generate all the
contents, which is hardly efficient). Thus, a reported size of 0 is
preferable. That way, if you rely on reading the file size, you will
*always* get wrong results. This makes buggy programs obvious and
repeatable, which is much preferable to covering up the problem.

In this case, the NFS server that skips the read of a zero-byte file is
the buggy program, and the current implementation of /proc makes this

[to recap: we're not talking about 'special file sizes' -- we're talking
about repeatable behaviour.]
@ @
C. Scott Ananian: / Declare the Truth boldly and
Laboratory for Computer Science/Crypto / without hindrance.
Massachusetts Institute of Technology /META-PARRESIAS AKOLUTOS:Acts 28:31
-.-. .-.. .. ..-. ..-. --- .-. -.. ... -.-. --- - - .- -. .- -. .. .- -.
PGP key available via finger and from

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