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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
