[OpenAFS] Windows Client, quota and filemanager - no warning!
Todd M. Lewis
utoddl@email.unc.edu
Wed, 11 Jan 2006 15:12:02 -0500
Jeffrey,
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.
--
Todd_Lewis@unc.edu
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.
>>
>>ted
--
+--------------------------------------------------------------+
/ Todd_Lewis@unc.edu 919-445-9302 http://www.unc.edu/~utoddl /
/ With her marriage she got a new name and a dress. /
+--------------------------------------------------------------+