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
smime.p7s
Description: S/MIME Cryptographic Signature
