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

[Steve Simmons]

Hmmm. Then why do links created on 1.7 clients work on 1.5 clients? Did =
we just get lucky on that one (and no, that's not sarcasm. With windows, =
sometimes you do get lucky when it attempts recovery).

Steve

On Aug 23, 2012, at 5:24 PM, Jeffrey Altman wrote:

> Shortcuts are tied to the "network provider name" just as drive letter=20=

> mappings are.
> A shortcut created with the 1.6 or earlier OpenAFS client is using the=20=

> Microsoft SMB redirector and the "Microsoft Network" provider.
> A shortcut created with the 1.7 or later OpenAFS client is using the=20=

> OpenAFS redirector and the "OpenAFS Network" provider.
>=20
> UNC paths are tied to the network provider.  When the "Microsoft=20
> Network" is asked for the path, \\afs\cell\foo it will report that it=20=

> doesn't exist even though the file system interface says it does.  =
This=20
> is not a bug but a limitation of the conversion from relying upon=20
> Microsoft's SMB redirector to a dedicated AFS redirector.
>=20
> Jeffrey Altman
>=20
>=20
> On Thursday, August 23, 2012 4:41:41 PM, Steve Simmons wrote:
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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
>>=20
>> Steve_______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20