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.

The hard link is its own target. You're thinking of a hard link as if it refers to something else. It doesn't. The hard link is just another name for the same thing. — Raymond Chen, Apr 21 '12 at 17:21
Looks like I completely misunderstood the functionality of hard links. I may be misunderstanding here, so I'd like to give an example scenario. I create a file named, "data.txt" and fill it with content. I then create a hard link for the file called "other.txt". From what I'm understanding, if I were to now delete data.txt and empty the recyling bin, other.txt would not be changed, because it's a file entry referencing the same content, not the file itself. Does that sound right? — Charles Grunwald, Apr 21 '12 at 22:19
Correct, they are just extra names for the same content (and some metadata). — Deanna, Apr 23 '12 at 10:47
The term "content" is ambiguous here. Both data.txt and other.txt are just two names for the same file. They share a common mft node. Only the file name and parent reference number is different. A file is marked as deleted when the hard link count is 0. — Kamaal, Dec 13 '20 at 22:39

score 2 · Accepted Answer · answered Jul 11 '12 at 00:18

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.

@raymond-chen: That would be ideal for Windows Vista and higher versions. He already found an answer that mention `FindFirstFileNameW`, but he does not seem to notice it. Or perhaps, he fails to mention that he can not use `FindFirstFileNameW` for some reasons. — Jay, Jul 11 '12 at 00:56

score 0 · Answer 2 · answered Apr 21 '12 at 20:58

0

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.

answered Apr 21 '12 at 20:58

Mahmoud Al-Qudsi

28,357
12
85
125

score 0 · Answer 3 · answered Jun 23 '20 at 02:55

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;
}

score 0 · Answer 4 · answered Dec 13 '20 at 00:17

0

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

answered Dec 13 '20 at 00:17

Charles Grunwald

1,441
18
22

Programmatically finding the target of a Windows Hard link

4 Answers4