-- Jeffrey Altman - 14 Jun 2008

This page provides a partial list of the work that must be done to update the AFS Servers on the Microsoft Windows platform.

?NetRestrict and ?NetInfo configuration files

The Windows AFS Servers (nor the client) has no support for the AFS ?NetRestrict and ?NetInfo files. This makes it very difficult to deploy servers on Windows systems which often include a variety of network adapters beyond just the physical adapter. The location of AFSDIR_SERVER_NETRESTRICT_FILEPATH and AFSDIR_SERVER_NETINFO_FILEPATH have already been defined in src/util/dirpath_nt.h and src/util/dirpath.c.

The NT vol back end

The NT vol back end (ntops.c) is based upon the ?NameI back end for UNIX but is designed to work with NTFS. Over the years the UNIX ?NameI back end has received a number of bug fixes and improvements. We need to verify that none of these changes must also be implemented for the NT back end. link to namei_ops.c cvs history

Need to modify the mappings of vice partitions to NTFS disk locations. Would prefer to permit arbitrary paths to the current drive letter mapping.

Now that DAFS has been implemented we may want to restart the NT vol backend from scratch.

Missing command line parameters


There are a number of random comments in the code choosing arbitrary values for Windows. Must replace arbitrary decisions with values based upon the actual capabilities of the system.

Ignore kaserver

Assume that kaserver does not exist. Instead, we will count on the presence of either Active Directory or some external krb5 kdc.


  • ?ProcessSize and STATS64_PROCESSSIZE should be set to the Private Bytes allocation for the current process. Use ?GetProcessMemoryInfo().

  • The arbitrary definiton of NT_OPEN_MAX should be replaced by an attempt to read the value of HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\USERProcessHandleQuota which has a default value of 10,000 if the registry value is not present.

FSync Interface

  • The FSync interface is UNIX optimized. Replacing FSync with a Windows specific LPC mechanism should be examined.

Bos Server

  • The Bos server process is wrapped with an NT Service "BosCtlSvc". There might be a better way to handle this.

Server Configuration

  • The Windows client now reads all of its data from the registry. Even the CellServDB has a registry equivalent although it is not required.

  • At present the configuration files match those of the Unix implementation. Providing a registry based alternate might be desirable in some environments.