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

Jeffrey Altman jaltman@your-file-system.com
Mon, 27 Aug 2012 17:45:46 -0400


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

To be more precise, the LNK data structure embedded the Network Provider
ID for which the path is valid.  When a Shortcut generated with the SMB
interface is accessed, the Network Provider is 0x00020000 which means
the path is for the LanMan SMB Redirector.  Since this Network Provider
exists on systems with the AFS Redirector in use, the shortcut is
evaluated by querying LanMan which says that it does not know how to
access \\AFS.

When the Shortcut generated with the AFSRedirector is accessed on a
system without the AFSRedirector, the network provider is unknown to the
system and a query to all network providers is issued.  In that case the
SMB redirector can access \\AFS and says so.

There is nothing magical or random here.

Jeffrey Altman


On 8/27/2012 12:29 PM, Jeffrey Altman wrote:
> AFS doesn't support ObjectIDs so there is no AFSRedirector specific dat=
a stored in the .LNK file.
>=20
> Jeffrey Altman
>=20
>=20
> On Aug 27, 2012, at 12:18 PM, Steve Simmons <scs@umich.edu> wrote:
>=20
>> Hmmm. Then why do links created on 1.7 clients work on 1.5 clients? Di=
d 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 lette=
r=20
>>> mappings are.
>>> A shortcut created with the 1.6 or earlier OpenAFS client is using th=
e=20
>>> Microsoft SMB redirector and the "Microsoft Network" provider.
>>> A shortcut created with the 1.7 or later OpenAFS client is using the =

>>> 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.  Th=
is=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 o=
ur Engineering colleges have been working together to try and figure out =
some odd performance when using the Windows client. We now have a consist=
ent and reproducible example. At this point I lean towards it being an AF=
S 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-2=
1
>>>> Clients: All windows are Windows 7 SP1m running Openafs 1.5.78, Open=
afs 1.7.14, Openafs 1.7.17, all from openafs.org.
>>>>
>>>> The problem was first noticed when using a Windows shortcut (.lnk fi=
le) 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 t=
he 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, n=
ot an earlier 1.7), users reported they could no longer drop files in. In=
stead they got an error panel indicating \\afs was full. Not the volume i=
nvolved, but \\afs. They were able move files in and out of the volume us=
ing 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 cr=
eated 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 modifie=
d (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, t=
he 1.5 shortcut fails. Editing it as described above heals it.
>>>>
>>>> This problem doesn't occur anywhere else we know of, and all the sys=
tems involved are running the same release of Windows as above. It's poss=
ible this is some subtle Windows issue that's only tickled by OpenAFS; af=
ter 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 st=
ep.
>>>>
>>>> Steve
>>>>
>>>> Steve_______________________________________________
>>>> OpenAFS-info mailing list
>>>> OpenAFS-info@openafs.org
>>>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>>
>>
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20


--------------enigF019B121D4A3B284C0E51712
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)

iQEcBAEBAgAGBQJQO+qQAAoJENxm1CNJffh4B1gH/R4SoiDZJK9HevjcFDh/DjZL
OADJlWpKRgEANEi4tk57uq7Tj1v0RmQegbqGcceHuEq5LdiPsFQLdTRtioTENF1B
ZbGo65VA5hmEB2FImAhAZasaqzS00dJbr0LpwdfUx9yaSaEsc8/9ReQS/NZC8K6L
/fOkjkLPm2RluJKNN+B5/CeUivQgT+0/SsC0CdnwO9GjxiQ9P2D+Pynoo4Mh2DQ8
A61tzFfqEVgc36xjnpzDSgm47JSDvlTQHl6y8hYJhYM7xh5K72+J9fgncDt5pWx1
bscHQO0J2dfd0JZn73bc4DQmrTwZsjChgQrQdiODj/R51JJvzkByxpE4Kbb4cr0=
=uLNF
-----END PGP SIGNATURE-----

--------------enigF019B121D4A3B284C0E51712--