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

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5BF0199432565DA1BDE27B45
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

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.

Jeffrey Altman


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 som=
e 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 c=
lient problem on Windows, but will leave that to folks who understand thi=
s 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 li=
nks 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 vol=
ume 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. Inste=
ad they got an error panel indicating \\afs was full. Not the volume invo=
lved, 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 dr=
ives, they could move files in and out of the AFS home dirs.
>
> Eventually it was determined that the problem was using shortcuts creat=
ed under 1.5 on a client running 1.7. If the 1.5-created shortcut was rem=
oved and recreated, it worked. If the 1.5-created shortcut was modified (=
pointed to a different location) and then pointed back to the original lo=
cation, it worked. 1.5-created shortcuts, 1.7-created shortcuts and 1.5-m=
odified-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 system=
s involved are running the same release of Windows as above. It's possibl=
e 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 bu=
g that only affects it, so mentioning it here first seemed the best step.=

>
> Steve
>
> Steve_______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info


--------------enig5BF0199432565DA1BDE27B45
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQNp+rAAoJENxm1CNJffh47k0IAJMHWd6aU/wphFEl2S6l2EFk
PMkq7dCduBMzfFATk8nUTDpa0XFDRmhkN53jtYk7tXljJR3v2vMn4LIeGh0vuony
7qj6Oj0XVEJsrE7FZE/3A0Ae+aSkszHXZUX1u66wvmjIuUF22Jg6yyrW8vWJ5uLo
kO1JNmMUW253sKvcS534hLe6/RCKfyInPTGG2EHpOEwClObL8SJp5Uv4sMk5xrSE
RZcKq0DWOyhNrWrvXIrJD3WVV69tf0FGVRMh4dRXDDZYnTZjK9tCoJlSzJpDF+Pk
TNyCFbf+WFnMJsFoOPibcvi6ObAPSATypWzGZElsddNujYNapJdVSY2baLaBx6c=
=Kf7r
-----END PGP SIGNATURE-----

--------------enig5BF0199432565DA1BDE27B45--