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 majordomo@vger.rutgers.edu