[OpenAFS] Possible bug in Windows AFS client handling older shortcuts
Mon, 27 Aug 2012 12:29:23 -0400
AFS doesn't support ObjectIDs so there is no AFSRedirector specific data sto=
red in the .LNK file.
On Aug 27, 2012, at 12:18 PM, Steve Simmons <email@example.com> wrote:
> 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, somet=
imes you do get lucky when it attempts recovery).
> 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.
>> 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 E=
ngineering colleges have been working together to try and figure out some od=
d performance when using the Windows client. We now have a consistent and re=
producible example. At this point I lean towards it being an AFS client prob=
lem on Windows, but will leave that to folks who understand this stuff bette=
>>> 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) i=
nto AFS. A group was using a shared AFS volumes and most members had links d=
irectly 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 a=
n earlier 1.7), users reported they could no longer drop files in. Instead t=
hey got an error panel indicating \\afs was full. Not the volume involved, b=
ut \\afs. They were able move files in and out of the volume using other met=
hods (scp), and if their AFS home directories were on mapped drives, they co=
uld move files in and out of the AFS home dirs.
>>> Eventually it was determined that the problem was using shortcuts create=
d 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 s=
ame location under 1.7. Under 1.5, both shortcuts work. Under 1.7, the 1.5 s=
hortcut 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 th=
is is some subtle Windows issue that's only tickled by OpenAFS; after all, i=
t's Windows. But that means it's either the OpenAFS client or a bug that onl=
y affects it, so mentioning it here first seemed the best step.
>>> OpenAFS-info mailing list
> OpenAFS-info mailing list