For filesystems that support them, hard links are essentially arbitrary names used to expose a particular file's data at one or more locations within the filesystem's directory structure. For example, while not typically referred to as such, a file's "original" file name is technically a hard link in such a filesystem.
Expanding upon the above example, hard links could be thought of as "additional" names for the "original" file (although a file's "original" name technically isn't any more important than any "additional" names for it that may exist elsewhere the filesystem). Regardless of the order in which they are created and deleted, or their location within the directory structure, all of the names (that is, hard links) for a particular file are equivalent because they all reference the exact same file data.
Due to this equivalence, a CBFS-based virtual filesystem that indicates support for hard links (see below for details) must be sure to handle file deletion requests carefully. When such a request arrives, the application must check how many hard links to the actual file data remain after removing the requested one; the file data should not actually be deleted until the last hard link has been deleted.
Finally, note that hard links, by definition, can only refer to files. Directories only ever have one name, in one location, within a CBFS-based virtual filesystem (in order to avoid recursion).
Hard links are a powerful and complex feature of Windows filesystems; and for clarity and brevity, this overview omits many details not relevant to understanding how the CBFS class interacts with them. To learn more about hard links, please refer to Microsoft's Hard Links article.
Supporting Hard Links with CBFS
In CBFS, the UseHardLinks property is used to indicate whether a virtual filesystem supports hard links; it is disabled by default. Virtual filesystems that do advertise hard link support must also support file Ids and Id-to-name resolution.
When hard link support is enabled, the following events must be handled by the class:
Additionally, the GetFileInfo event handler must always be sure to return the number of hard links a file has by setting the HardLinkCount event parameter appropriately.
Finally, as described above, the application must be careful to only delete file data after the last hard link to a file has been deleted.