File paths are expressed to the Policy DLL via an FE_POLICY_PATH_INFORMATION structure. This structure is used to describe both local file paths as well as network file paths.
In the case of a local file path, the volume GUID of the local volume is supplied along with the volume relative path to the file. The Policy DLL may use the volume GUID to look up a “friendly name” for the volume, such as a drive letter or mount points, using standard Windows APIs. The Policy DLL may also call the FESF Utility function FesfUtil2GetFullyQualifiedPath, which will attempt to convert the volume GUID into a friendly name and concatenate the supplied relative path. You can read more about volume GUIDs, drive letters, and mount points by consulting the MSDN documentation.
If the volume GUID supplied is FE_NETWORK_GUID, the path supplied represents a file located on a network share. Network shares do not have volume GUIDs and thus this GUID is meaningful only within the bounds of the FESF Policy DLL interface and as input to the FesfUtil2 function FesfUtil2GetFullyQualifiedPath. The server and share are supplied along with the share relative path to the file.
Network paths have some potentially unexpected behaviors that warrant additional discussion. Of particular note is the fact that FESF components make no attempt to normalize or rationalize the server component of the UNC path. For example, let’s assume that there is a server EmployeeFiles in the FESFTest domain with two IP addresses 10.0.0.10 and 10.0.0.11. A user might access a file on this server using any one of these paths:
•\\EmployeeFiles\Records\Doe.docx
•\\EmployeeFiles.FESFTest.com\Records\Doe.docx
•\\10.0.0.10\Records\Doe.docx
•\\10.0.0.11\Records\Doe.docx
In each of these cases, the Policy DLL will see the server name as specified by the requestor. Thus, if the Policy DLL is using a strict path based policy these paths may appear to represent different files located on different servers. If the Policy DLL requires a unique canonical name to represent the server, the Policy DLL must extract the server component of the supplied server and share information and use an external source to resolve the name.
Another interesting case is when the user accesses a network share via a drive letter mapping. For example, a user may map her Z: drive to the \\EmployeeFiles\Records share. If the user then accesses Z:\Doe.docx, the Policy DLL will not see the drive letter based path in its callbacks. As stated previously, FESF always passes the Policy DLL a standard UNC path, even if the file access was made via a drive letter mapping. Note that the server component of the path is still subject to the ambiguity specified above, but in this case it is dependent on the server name format used when the drive letter mapping was created.
If the volume GUID supplied is FE_SHADOW_VOLUME_GUID, the path supplied represents a file located on a local shadow volume. Shadow volumes do not have volume GUIDs and thus this GUID is meaningful only within the bounds of the FESF Policy DLL interface and as input to the FesfUtil2 function FesfUtil2GetFullyQualifiedPath. Paths to files on shadow volumes carry the shadow volume “device name”. This can be used as input to find out more about the shadow volume. For instance, the VSS APIs provide such support. A file on a shadow volume can be opened by constructing a UNC file name by appending the file name to the shadow volume device name and prepending the while with \\?\GlobalRoot\
Thus:
\\?\GlobalRoot\device\HarddiskVolumeShadowCopy9\dir\file