Programmatically finding the target of a Windows Hard link

Question

I've been playing around a lot recently with manipulating reparse points programmatically, and something's been bugging me for a little while now. Since Windows hard links aren't reparse points like junctions or symbolic links, they can't be accessed the same way. Creating a new one is easy enough, but I've yet to figure out how to read the target of one. Since extensions like Hard Link Shell Extension have property sheets displaying that information, I assume it can be done, but I've been unable to find any documentation on how. (I did notice that the shell extension doesn't indicate which file is the real thing on hard links, though)

I did find this answer, which explains how to count the links to a file, but unfortunately, I'm still stuck on resolving.

Answer 1

Hardlink information are stored in $FILE_NAME attributes using POSIX name. Each of these attributes refers to a file which may refers to the original file itself. A file without any hardlink may also have a POSIX name. In other words, a hardlinked file always has multiple POSIX names. The attribute's DirectoryFileReferenceNumber field points to an MFT entry index, which is the folder entry that contains the file.

Here are the guide to retrieve all targets of a file, whether it's hardlinked or not.

You will need to use FSCTL_GET_NTFS_FILE_RECORD on a file to get all of its NTFS attributes and parse it to retrieve each $FILE_NAME attribute.

On each $FILE_NAME attribute, use FSCTL_GET_NTFS_FILE_RECORD on the volume where the file resides using its DirectoryFileReferenceNumber as MFT entry index to retrieve the file's folder container information. This folder is the lowest level that contains the file. For example, if the file path is C:\MyData\Myfiles\MyDocument.txt, the lowest folder level is MyFiles. If the DirectoryFileReferenceNumber points to the root folder, which is 0x5, then you have the full path of the file. For example, C:\MyDocument.txt.

With that folder information, if it is not a root folder, you simply repeat a similar task as above which is to retrieve the folder name from the Name field of $FILE_NAME attribute. But this time, the NameType does not have to be of POSIX type and any can be used. Preferably LFN or LFN & DOS8.3 compatible type. Use its DirectoryFileReferenceNumber to get the upper folder level and repeat the task in this paragraph. When the DirectoryFileReferenceNumber points to the root folder, which is 0x5, then this repeating tasks has completed since you already have the full path of the file.

Now you have resolved one file target. The next task is to process the next $FILE_NAME attribute whose NameType is of POSIX type. Process all of them to get all file targets. Do not use this method to find out whether a file has hardlinks or not. Instead, use GetFileAttributes function since it is a lot faster.

Answer 2

We wrote a C++ library dedicated to Junction Points on Windows, and it's open source under the MIT license. Whether or not this is what you want is unclear from your question, as you say hard links but then ask how to resolve them.

Answer 3

to check if a file has a hard link, using GetFileInformationByHandle

typedef struct _BY_HANDLE_FILE_INFORMATION {
  DWORD    dwFileAttributes;
  FILETIME ftCreationTime;
  FILETIME ftLastAccessTime;
  FILETIME ftLastWriteTime;
  DWORD    dwVolumeSerialNumber;
  DWORD    nFileSizeHigh;
  DWORD    nFileSizeLow;
  DWORD    nNumberOfLinks;     <--- if this value is more than 1, then we have hard links
  DWORD    nFileIndexHigh;
  DWORD    nFileIndexLow;
} BY_HANDLE_FILE_INFORMATION, *PBY_HANDLE_FILE_INFORMATION, *LPBY_HANDLE_FILE_INFORMATION;

then for vista or later, using FindFirstFileName/FindNextFileName to get target.

for earlier system version, traverse the whole volume and comparing nFileIndexHigh and nFileIndexLow, once found, --nNumberOfLinks, print the target name, until nNumberofLinks==1, then quit.

this is the way I found in FindLinks.exe by reversing the binary.

    if ( _wcsicmp(dword_422154, lpFileName) )
  {
    sub_402580(v4, (DWORD *)&v8, (int)&fileindexlow, (int)&v11);
    if ( fileindexlow == a3 && fileindexhigh == a4 )
    {
      wprintf(L"\r          \r%s\n", v4);
      if ( --*v5 == 1 )  //numoflinks
        exit(0);
    }
  }


char __usercall sub_402580@<al>(LPCWSTR lpFileName@<ecx>, DWORD *a2@<edx>, int a3, int a4)
{
  DWORD *v4; // edi
  DWORD v5; // eax
  HANDLE v6; // esi
  DWORD v7; // ecx
  const WCHAR *lpFileNamea; // [esp+Ch] [ebp-40h]
  struct _BY_HANDLE_FILE_INFORMATION FileInformation; // [esp+14h] [ebp-38h]

  v4 = a2;
  lpFileNamea = lpFileName;
  v5 = GetFileAttributesW(lpFileName);
  if ( v5 == -1 )
    return 0;
  *v4 = 0;
  v4[1] = 0;
  *(_DWORD *)a3 = 0;
  *(_DWORD *)(a3 + 4) = 0;
  *(_DWORD *)a4 = 0;
  v6 = CreateFileW(lpFileNamea, 0x80u, 7u, 0, 3u, (v5 & 0x10) << 21, 0);
  if ( v6 == (HANDLE)-1 )
    return 0;
  if ( GetFileInformationByHandle(v6, &FileInformation) )
  {
    *(_DWORD *)a4 = FileInformation.nNumberOfLinks;
    v7 = FileInformation.nFileSizeHigh;
    *v4 = FileInformation.nFileSizeLow;
    v4[1] = v7;
    LOWORD(v7) = FileInformation.nFileIndexHigh;
    *(_DWORD *)a3 = FileInformation.nFileIndexLow;
    *(_DWORD *)(a3 + 4) = (unsigned __int16)v7;
  }
  CloseHandle(v6);
  return 1;
}

Answer 4

Just in case anyone else comes looking for this information, I've decided to post a small POC I wrote after this question was answered. It's based off of the steps Jay described and should be compatible with Windows XP and later OSes.

POC Code