[OpenAFS] Windows Client, quota and filemanager - no warning!

Todd M. Lewis utoddl@email.unc.edu
Wed, 11 Jan 2006 15:12:02 -0500


Your explanation of the error flows through the various levels is 
informative, and I believe you are 100% right on the level you are 
talking about.

 From the user's perspective, however, all he sees is that he goes to 
move/copy a file with the standard tools the Desktop provides, and the 
operation goes on forever.

I agree with you that the Application -- in this case Microsoft's 
Drag'n'drop dead GUI -- is not doing what needs to be done, and it's 
clearly at fault. I'll go further and say that the few kludges I've 
thought up to somehow detect this problem and mitigate its effects (like 
noticing that we're getting gobs of VOVERQUOTA in a short period and 
perhaps putting up a message box to that effect on the screen) are just 
that -- horrible hacks that anybody with any sense of design would like 
to avoid.

Maybe Vista will do the Right Thing, or perhaps something right enough, 
so that the user gets a clue. In the mean time, the current system as a 
whole behaves badly in this circumstance, and the user doesn't 
particularly care which component is at fault.

There's a subtle difference between being right and being correct. I 
think your components are right, but the system as a whole is not 
correct, and fixing the user level application(s) in this case is not an 
option. Given that, and the fact that, as you explained, passing errors 
up the chain isn't solving the problem, the question then becomes, "Is 
there anything else, within reason, that can be done to inform the user 
that there may be something amiss?"  The answer may very well be, "Not 
really," and I'd be surprised if there's anybody else on the list (or 
OpenAFS-devel, which is where this should probably be anyway) in a 
better position -- either skill-set or experience-wise -- to answer that 
question than you. But restating with increasing degrees of detail that 
the existing OpenAFS components are handling return codes properly 
doesn't really address the larger issue.

Jeffrey Altman wrote:
> The AFS Cache Manager cannot speak directly to the user.   When the
> VOVERQUOTA is received it is delivered to the application in this
> manner:
>                               VOVERQUOTA
>                                   |
>                                   |
>                          +-----------------+
>                          |AFS Cache Manager|
>                          +-----------------+
> 				  |
>                           +---------------+
>                           |SMB/CIFS Server|
>                           +-------.-------+
>                                   |
>                                   '
>                          STATUS_DISK_FULL
>                                   |
>                                   |
>                        +----------'--------+
>                        |Windows CIFS Client|
>                        +-------------------+
>                                   |
>                             +---------+
>                             |Win32 API|
>                             +---------+
>                                   |
>                            +-----------+
>                            |Application|
>                            +-----------+
> It is not possible for the AFS Cache Manager to determine what the
> application does with errors.
> If you have some evidence that the AFS Cache Manager is ignoring
> errors from the AFS File Server, please provide some evidence.
> Otherwise, you should speak with the developers of your applications.
> Jeffrey Altman
> ted creedon wrote:
>>It appears that windows does not correctly pass the message on to the
>>user, therefore it would be convenient if the client did.
>>As I recall, the message box is indecipherable.
   / Todd_Lewis@unc.edu  919-445-9302  http://www.unc.edu/~utoddl /
  /       With her marriage she got a new name and a dress.      /