[OpenAFS] Possible bug in Windows AFS client handling older shortcuts

[Steve Simmons]

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.=20

Steve

Steve=