Drives mapped in the system context are deprecated by Microsoft and cause numerous problems for the Microsoft SMB redirector and several anti-virus solutions. They really need to be avoided. If there is a drive letter that you want mapped within each logon session I recommend developing your own Network Provider that executes a custom logon script that will perform the desired mapping.
That being said, let me explain the changes to the pioctl interface post-1.5.35. For years users of OpenAFS have complained that on some systems (but not others) the presence of the AFS Explorer Shell extension has resulted in extremely long delays when attempting to access the context menu. During the development work for the AFS redirector client Peter Scott and I finally identified what the problem was. The pioctl interface on Windows is implemented as a transceive operation on a special file name _._AFS_IOCTL_._. This file is opened in the current directory of the explorer shell and if that fails, within \\<AFS>\all\. Opening the file in the current directory permits the drive mapping context to be transmitted to the AFS SMB server. What happens if the current directory is not mapped to AFS? Well, depending on what the drive letter is mapped to or what the current UNC path is, it might result in a long timeout waiting for a hardware device to become available, or a network browsing attempt to complete, or .... This in turn resulted in the very long delays that were being seen which can be on the order of minutes. For the affected users, this makes it is impossible to use the AFS Explorer Shell extension but more often resulted in the user refusing to use OpenAFS. The only safe way to implement this functionality is to ensure that the CreateFile on _._AFS_IOCTL_._ only occurs if there is a strong likelihood that the device is in fact an AFS device. The pioctl interface now has a very complicated series of checks that examines the current path to identify what the real device name is. It handles SUBST, NET USE, MAP, and several other combinations. So what is the problem with global drive letter mappings? A global drive letter mapping does not expose any of the details of what the drive letter is mapped to. Instead it is reported as a local disk device. As a result there is no method by which the pioctl interface can use the file system apis to determine that it is in fact an AFS device. The pioctl interface does attempt to get around this problem by using the afsd_service configuration. If the drive mapping is configured using the ...\TransarcAFSDaemon\Parameters\GlobalAutoMapper functionality, then the pioctl interface will be able to find the drive letter and determine that it is in fact mapped to AFS. Otherwise, as far as the pioctl interface is concerned, the device is a local disk and it would be too risky to attempt to open _._AFS_IOCTL_._ on it. I hope that helps. Jeffrey Altman Justin Brinegar wrote: > After upgrading to version 1.5.60 on Windows XP, the AFS Windows > Explorer extension no longer functions on drives mapped in the system > context*. This symptom was not seen in 1.5.35, and the symptom still > exists in 1.5.61. > > Is this change by design? Is there any way to re-enable the functionality? > > We are currently directing our users to type in the full UNC path to the > mapped system drive that they would like to use the AFS Explorer > Extension on, which presents the afs path to them in a user context. > > *Note: This is used for folder redirection. File change operations do > not work properly (folder refreshing) over UNC paths in Windows XP. > > Thanks, > Justin _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
