It has come to our attention that the 1.7 series OpenAFS clients for 
Windows may refuse to copy files to AFS volumes in some circumstances.

When using Explorer to drag-and-drop files, with a destination window 
opened to a UNC path (e.g. \\afs\northstar.dartmouth.edu\users\x\x.....), 
you may get a pop-up notice that there is not enough free space on the 
destination server.  This message is bogus, and is caused by the file 
server returning invalid data to the 'query server space' call, when the 
file servers are > 2TB in size.

The work-around is to map a network drive to the location in AFS, and then 
open a window on the network drive.  The free space query for mapped 
drives uses a different mechanism.

Command line copy seems not to check destination free space, and so is not 
affected.  Other software writing directly to AFS space may also be 
affected, but should also be fixed by using a mapped drive.

There is a patch for the file servers to make large partitions return 
valid data to clients requesting free space information, but it will take 
some time to test and upgrade the file servers.

As far as we know, no other client versions will block writes to AFS based 
on the server space information, although all clients get incorrect data 
until this patch is applied.

Richard
-- 
Richard Brittain,  Research Computing Group,
                    Computing Services, 37 Dewey Field Road, HB6219
                    Dartmouth College, Hanover NH 03755
[log in to unmask] 6-2085