[OpenAFS] interesting situation

[Derrick J Brashear]

On Tue, 1 Jul 2003, Klaas Hagemann wrote:

> >
> > It was not, that I've seen, but I'm going to have to look in context. We
> > should be able to fix this bug by 1.2.10-release, but it's not clear yet
> > that the included patch won't have other unintended side effects, notably
> > on non-Linux platforms.
>
> There might be different error codes on different platforms? But which
> platform does it depends on? The client side or the server side?
> We have linux clients so we thought that theses error codes should be
> compatible with linux.
> Do i have to care about the system on the (file)-server side? It does
> not matter for me since it is linux, too, but maybe this could affect
> someone else?

In fact, 108 is intended to be outside the error code range, an AFS-only
error, to be translated back on the client. Worse, EDQUOT isn't the same
across all linuxes, so if you hardcode it to 122, you're screwing
yourself.

Applying the patch you sent is really a bad idea. afs_analyze.c instead
should translate, thusly:
--- afs_analyze.c       12 May 2003 15:16:24 -0000      1.6.4.5
+++ afs_analyze.c       1 Jul 2003 23:43:03 -0000
@@ -129,6 +129,17 @@
        return EWOULDBLOCK;
     if (acode == VNOVNODE)
        return ENOENT;
+    if (acode == VDISKFULL)
+       return ENOSPC;
+    if (acode == VOVERQUOTA)
+       return
+#ifdef EDQUOT
+           EDQUOT
+#else
+           ENOSPC
+#endif
+           ;
+
     return acode;

 } /*afs_CheckCode*/