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
