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