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
