On Tuesday, November 15, 2005 03:49:46 PM +0100 Peter Somogyi <[EMAIL PROTECTED]> wrote:
I've examined FDH_READ implementation, it's a standard read. I've read its manual (man 2 read), and it tells "[...]it is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal)[...]". So I think instead of null padding it should continue reading (if n>0, of course) - at least on Linux platform. Am I right?
The documentation of read(2) tends to be a little bit abstract. Access to plain files is "fast"; there is no possibility of blocking or getting a short read because there is more data coming that hasn't arrived yet. You can get a short read if you hit EOF, but the files that DumpFile() are reading are of known size, so a short read means there was a real error, either during the read or (more likely) because the contents of the disk aren't what they're supposed to be. There's never going to be more data. It becomes necessary to pad the output buffer because the dump tag which indicates how many bytes are coming has already been sent, and so we have to fulfill that requirement or they won't be able to process the rest of the dump.
Another question is about rx_Write(call, buf, nbytes): is it true that writting less (but >0) than nbytes means an error? (in case of file write: it's also not an error)
write(2) is very similar to read(2) in this respect. A short write on a plain file always indicates a problem; you really only need to be able to deal with short writes on "slow" file descriptiors like devices, pipes, or sockets.
In any case, rx_Write is not write(2). It's a little hard to tell without carefully analyzing the code, but rx_Write will never return a short write; it will always return either the full number of bytes written or zero, with the latter indicating an error.
-- Jeff _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
