(Illustration by Gaich Muramatsu)
Hi Jan, that's awesome news, the changes are appreciated deeply. On Thu, Apr 05, 2007 at 11:07:14PM -0400, Jan Harkes wrote: > really only have to avoid connecting for read operations. This can be > done by failing in userent::Connect for any unauthenticated connections. > The only problem is what errorcode we should return so that it is > handled correctly on the way out (and so that the error makes sense to > the end-user/application). > > Maybe EPERM or EACCESS, there are also a bunch of other errno's that may > work but I'm not sure how if they are supported across different > platforms and how applications would respond if they get any of these > errors as a result of a file system syscall (open/close/stat). I It is hardly possible to choose a value good for all possible platforms and applications. Applications will be also presumably drifting towards more awareness of temporary/non-fatal error conditions. To help them distinguish such situations more error values would be desired (may the standards follow) - but as the last resort we have ETIMEDOUT. As misleading as it is, it indicates something non-fatal/retryable, potentially correctable. On the practical side, I guess EPERM/EACCESS are pretty much "good enough". Seeing "Connection timed out" is also ok with me, especially given an independent indication of availability of the servers (like "cfs cs" or vcodacon or something) so that the user realizes there is another problem than a network or server failure. Regargs, RuneReceived on 2007-04-06 05:19:36