Messages in this thread | | | Date | Fri, 22 May 1998 17:20:49 +1000 | From | Kevin Lentin <> | Subject | Re: size of files in /proc |
| |
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. Comapred to: File has 100 bytes. NFS stats. File gets appended to. NFS reads and returns 200 bytes.
Or does NFS only ever return as much data on a read as a previous stat said there was to read?
> I see this argument as another reason to fix /proc
But HOW, when you don't know the sizes of the files?
-- [======================================================================] [ Kevin Lentin Email: K.Lentin@cs.monash.edu.au ] [ finger kevinl@fangorn.cs.monash.edu.au for PGP public key block. ] [ KeyId: 06808EED FingerPrint: 6024308DE1F84314 811B511DBA6FD596 ] [======================================================================]
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |