Windows 10 & 11 Hard Links: Create Files with mklink /H, Verify and Avoid Common Pitfalls

The one-command trick​

Onyimadu created original.txt in a Projects folder, then ran this in Command Prompt:

mklink /H C:\Test\Archive\second-name.txt C:\Test\Projects\original.txt

The /H switch makes the difference. The pattern is mklink /H linkName target. The new name comes first and the existing file second. Without a switch, mklink makes a file symbolic link by default, and /H creates a hard link instead.

Microsoft's own examples use the same form, and the Windows Commands documentation lists Windows 10, Windows 11 and recent Windows Server releases as supported.

To check the result, Onyimadu ran fsutil hardlink list C:\Test\Projects\original.txt. It printed both paths. Microsoft documents a second way to create a link, fsutil hardlink create <newfilename> <existingfilename>, which also takes the new name first. Microsoft's fsutil documentation also lists the list verb, which shows all hard links to a given file.

What a hard link actually is​

A hard link isn't a pointer or a copy. It's a second directory entry for the same file data, so neither path is the "original". Microsoft describes it as a directory entry for a file, and says every file already has at least one. Another link just adds a name.

On NTFS, a single file can appear in many directories, or in the same directory under different names. Programs can open any of those names and modify the file. NTFS reference-counts the data and removes it only when every hard link to it is gone.

What the author's tests showed​

These are the author's observations on one machine. They are not guaranteed results for every system.

• Edits show through both names. Onyimadu appended a line through the second name with echo and found it in original.txt. A Notepad edit and save also left both paths listed.
• Deleting one name loses nothing. After original.txt was deleted, second-name.txt still opened with the latest edits. Deleting the last name removed the file, and about 1 GiB came back on the C: drive in the large-file test.
• No second copy of the data. With a 1 GiB dummy file, free space dropped by about 1 GiB when the file was created. Adding the hard link reduced it by only 671,744 bytes, about 656 KiB. The author couldn't fully account for those extra bytes, and Microsoft doesn't document that figure. Treat it as one test's reading, not an expected value.

Microsoft's Win32 documentation adds a quirk the author didn't cover. File contents change instantly through every link. But the size and attribute information shown in a directory entry is visibly updated only at the link through which the change was made. Microsoft's example: clear the read-only flag on one link so you can delete it, and the other links still show read-only even though that's no longer true.

The Notepad caveat​

Notepad kept the link intact. Onyimadu warns that other apps may not. The risk is an app that saves to a temporary file and swaps it in for the original. That could leave the two names attached to different files. Microsoft's documentation says nothing about any particular app's save method, so this is a plausible failure mode, not a documented list of offenders.

The practical fix is to re-run fsutil hardlink list <full path to the file> after saving with an unfamiliar app. If both paths still appear, the link survived. Use a real filename rather than a bare period as the argument.

Where hard links stop working​

The limits are firm, and Microsoft's documentation lists them:

• Same volume only. Microsoft's examples allow C:\dira\ethel.txt linked to C:\dirb\dirc\lucy.txt, and reject a link from C: to D:. Mapped network drives are rejected too. Onyimadu got the error "The system cannot move the file to a different disk drive." The boundary is the volume, not the drive letter.
• Files only. Microsoft says hard links can't reference directories.
• NTFS. Microsoft describes the feature as NTFS. A third-party guide notes that FAT and exFAT don't support hard links. That matters for USB sticks and SD cards.
• A link count ceiling. Wikipedia states that Windows enforces a limit of 1024 hard links to a file on NTFS volumes. That's rarely a concern, but it exists.

Hard link, shortcut, symlink or junction​

Onyimadu's comparison table has a quirk. It lumps "folders" in with symbolic links, but Microsoft also documents junctions for directories.

An NTFS symbolic link is not the same as a .lnk shortcut. A shortcut is an ordinary file, can exist on any filesystem, and isn't transparent to applications. A symbolic link records a path. If its target is deleted or renamed it goes stale, and if the target is replaced it points to the replacement. A hard link has no such failure mode because there's no target path to break.

One more tip: a symbolic link isn't always the right escape hatch. One third-party comparison says symbolic links need administrator rights unless Developer Mode is on. That claim comes from a single source I didn't confirm against Microsoft's documentation. Microsoft's pages don't state a privilege requirement for mklink /H, so I won't claim one either.

A short how-to​

1. Make sure the file and the destination folder are on the same NTFS volume, and that the destination folder exists. The new name must not already be taken.
2. Open Command Prompt and run mklink /H "<new path>" "<existing file path>". Quote paths that contain spaces.
3. Run fsutil hardlink list "<file path>" to confirm every name is listed.
4. After editing with a new app, run the list command again to confirm the link survived.
5. Delete names freely. Just remember you only free disk space when the last name goes.

Bottom line​

Hard links suit software that expects a file at a particular path while you keep one copy of the data. Examples are a large file needed in two project trees, or a log reachable from two app directories. They are not a backup. A change, a corruption or a final delete reaches every name at once.

The feature is old and well documented. The main thing readers tend to miss is the volume boundary and the way some apps save files. Test your own workflow once, with fsutil hardlink list, before you rely on it.