Re: size of files in /proc

Ton Hospel (thospel@mail.dma.be)
23 May 1998 12:33:56 GMT

In article <Pine.SUN.3.96.980522161128.13993V-100000@amsterdam.lcs.mit.edu>,
"C. Scott Ananian" <cananian@lcs.mit.edu> writes:
> On Thu, 21 May 1998 thospel@mail.dma.be (Ton Hospel) wrote:
>
> [quoting drastically curtailed. For context, see the archives]
>> "C. Scott Ananian" <cananian@lcs.mit.edu> 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

Nope, I think your missing my point. I agree that files should not rely on
e.g. size for setting up their buffer when doing a copy. They would be wrong.
I agree 100% with that.

> 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

Also true. Real sizes would be nice, but are in general too expensive and
not necessary ('though it could be done for more files than it is now)

> 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.

Not true. 0 is the ONLY size that fully determines the file contents. All
I'm asking is for ANY size different from 0. 1 would work perfectly.
>
> 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
> obvious.
> --Scott

No, it's size 0 thats buggy. Why should not a program that sees a zero
size file conclude it's empty ? That's plain normal semantics of size 0.
>
> [to recap: we're not talking about 'special file sizes' -- we're talking
> about repeatable behaviour.]
> @ @

Nope, were talking about a buggy /proc that screws up the semantics of
filesize.

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