The central support staff for the umich cell and support staff for our 
Engineering colleges have been working together to try and figure out some odd 
performance when using the Windows client. We now have a consistent and 
reproducible example. At this point I lean towards it being an AFS client 
problem on Windows, but will leave that to folks who understand this stuff 
better.

Servers: Linux from scratch, running OpenAFS 1.4.12 built  2010-05-21
Clients: All windows are Windows 7 SP1m running Openafs 1.5.78, Openafs 1.7.14, 
Openafs 1.7.17, all from openafs.org.

The problem was first noticed when using a Windows shortcut (.lnk file) into 
AFS. A group was using a shared AFS volumes and most members had links directly 
to the volume. Typical handling was done by clicking on the shortcut to bring 
up a windows explorer pane with the contents of the volume visible, then using 
drag/drop to move files in and out of AFS.

After upgrading to 1.7.14 (I think it was from some flavor of 1.5, not an 
earlier 1.7), users reported they could no longer drop files in. Instead they 
got an error panel indicating \\afs was full. Not the volume involved, but 
\\afs. They were able move files in and out of the volume using other methods 
(scp), and if their AFS home directories were on mapped drives, they could move 
files in and out of the AFS home dirs.

Eventually it was determined that the problem was using shortcuts created under 
1.5 on a client running 1.7. If the 1.5-created shortcut was removed and 
recreated, it worked. If the 1.5-created shortcut was modified (pointed to a 
different location) and then pointed back to the original location, it worked. 
1.5-created shortcuts, 1.7-created shortcuts and 1.5-modified-on-1.7 shortcuts 
all work on 1.5.

To reproduce this, we created a shortcut under 1.5, then another to the same 
location under 1.7. Under 1.5, both shortcuts work. Under 1.7, the 1.5 shortcut 
fails. Editing it as described above heals it.

This problem doesn't occur anywhere else we know of, and all the systems 
involved are running the same release of Windows as above. It's possible this 
is some subtle Windows issue that's only tickled by OpenAFS; after all, it's 
Windows. But that means it's either the OpenAFS client or a bug that only 
affects it, so mentioning it here first seemed the best step. 

Steve

Steve_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to