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

[ted creedon]

If the windows AFS client listened to the message, at least there would 
be some kind of warning.

tedc

Jeffrey Altman wrote:
>I should point out that the error that the OpenAFS 1.4.0 client reports
>in this case is STATUS_DISK_FULL ((NTSTATUS)0xC000007FL).  The reason
>the application is most likely hanging is that it either does not check
>the error code on the write() operation or it does not believe it.
>If the application responds to a disk full condition by checking the
>amount of free space and trying again (forever), it will lose.  This is
>because the amount of free space reported by AFS via the CIFS operations
>is always:
>
>  2,147,483,647 bytes total disk space
>  1,073,741,824 bytes used
>  1,073,741,823 bytes free
>
>Space queries are always performed against the root directory of the
>disk.  If we were to report the true size and free space/quota of the
>'root.afs' volume, then no one would ever be able to write to AFS at
>all.
>
>Jeffrey Altman
>
>
>Jeffrey Altman wrote:
>  
>>AFS is made up of volumes.  CIFS file shares are contiguous disks.
>>It is not possible to report to Windows a different quantity of
>>disk space, free space, etc. on a per directory basis.
>>
>>JPSoftware is the only vendor I am aware of that has added OpenAFS
>>support to their tools: 4NT and TakeCommand.   JPSoftware calls the
>>AFS pioctl() functions to obtain information about the true size of
>>volumes, the amount of free space, and quota limitations.
>>
>>This is not a bug in OpenAFS.  This is a limitation of the CIFS to
>>AFS gateway model used to implement the Windows client that can be
>>worked around by application vendors if they choose to support AFS
>>as a file system.
>>
>>Jeffrey Altman
>>    
>
>