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 data > stored in the .LNK file. > > Jeffrey Altman > > > On Aug 27, 2012, at 12:18 PM, Steve Simmons <[email protected]> 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, >> 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 >>> mappings are. >>> A shortcut created with the 1.6 or earlier OpenAFS client is using the >>> 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 >>> Network" is asked for the path, \\afs\cell\foo it will report that it >>> doesn't exist even though the file system interface says it does. This >>> is not a bug but a limitation of the conversion from relying upon >>> 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 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. >>>> >>>> Steve >>>> >>>> Steve_______________________________________________ >>>> OpenAFS-info mailing list >>>> [email protected] >>>> https://lists.openafs.org/mailman/listinfo/openafs-info >>> >> >> _______________________________________________ >> OpenAFS-info mailing list >> [email protected] >> https://lists.openafs.org/mailman/listinfo/openafs-info > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info >
signature.asc
Description: OpenPGP digital signature
