I don't have the appropriate context because I don't know what RPC the code in question is executing but the 1.4.10 file server does have a bug which can result in rx_Read() returning 0 octets to the first data read as part of an FetchData response which is not an indication of end of file or an error.
On 4/16/2013 9:55 PM, Robert Sturrock wrote:
> Hi All.
>
> (I'm not sure if this should go to openafs-info, or the devel list, so I
> apologise if I've gotten that wrong).
>
> We are using a small utility here, written by the good people at ltu.se, to
> backup our OpenAFS cell to TSM. The tool is "tsmafs"
> (/afs/ltu.se/misc/tsmafs/tsmafs-0.2.tgz), which includes a program called
> "tabackup" to perform the actual backup. We found what we believe is a bug,
> in which rx_Read() is used to read data from AFS, but the scenario where this
> returns 0 bytes is not checked.
>
> The outcome of this is that the tool would occasionally read 0 bytes and then
> continue on, assuming that it had successfully backed up the file in
> question, leaving perhaps only a fragment of the file on TSM.
>
> The code _was_ originally as follows (tabackup.c:storefile():322):
>
> if ((b = rx_Read(rxc, buf, len)) < 0)
> break;
>
> .. so we added the following extra sanity checking to detect this and raise
> an error:
>
> + if (b == 0)
> + {
> + rx_error_code = rx_Error(rxc);
> + warnx("zero length rx_Read for %s%s", hl, ll);
> + warnx("rx error (%ld) tsn (%lld) tsz (%lld) len (%d)",
> rx_error_code, tsn, tsz, len);
> + break;
> + }
>
> I suppose my question is: is it normal/ok for rx_Read() to return 0, or is
> this in itself indicative of a problem or bug somewhere?
>
> We are running OpenAFS 1.4.12-1.1.2 on the (RHEL5) client. Fileserver is
> 1.4.10 on Solaris-x86.
>
> Any pointers appreciated ...
>
> Regards,
>
> Robert.
> _______________________________________________
> OpenAFS-info mailing list
> [email protected]
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
smime.p7s
Description: S/MIME Cryptographic Signature
