[OpenAFS] Using the Windows Explorer extension on global drives

[Jeffrey Altman]

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