If you ask almost anyone where a file is on Windows, they’ll name a folder, and I would usually agree. But after making a single text file live in two different folders, with no copies involved, I started looking at things differently. There’s a built-in mechanism on Windows for this, and all you need is a single command.

I tested it by trying to break things; I edited, deleted, moved it between drives, and got results I didn’t expect.

One file, two folders

I checked whether Windows had stored another gigabyte

To start, I created a plain text file called original.txt, and placed it in a folder called Projects. Then I opened the Command Prompt and ran this command:

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

The command created a hard link, giving the same file data a second name: second-name.txt. It pointed directly to the same file’s data I had created. I got confirmation of my hard link when Windows printed both paths under the same file after I ran the command:

fsutil hardlink list C:\Test\Projects\original.txt

While it told me both names were connected, nothing had been copied. Next to both file names, File Explorer listed 1GiB, but this wasn’t much help. I needed more context, so I created a 1GiB dummy file and noticed the free space on my C: drive dropped by about 1GiB. Then I hard-linked it to the second folder and this time the free space dropped by only 671,744 bytes (about 656 KiB), not an entire gigabyte.

I still couldn’t account for the extra bytes, but the hard-link list confirmed that Windows hadn’t created another copy of the file’s data. It added a second name for that same file.

Edit one, change both

The catch is how your app saves the file

I appended a line to the second name using this command:

echo Added through the second name >> C:\Test\Archive\second-name.txt

I opened original.txt and that line was already there. No syncing or copying occurred; I had edited only one file.

Appending is the easy case because it writes directly into the existing file. The route most people would rather take is to open an app, edit the file, and save it. So I tried it. I opened second-name.txt with Notepad, and after making an edit, I saved it. Then I headed back to the Command Prompt and ran fsutil hardlink list.

Once again, I could see both paths listed with original.txt showing the changes.

I only tested using Notepad, so this may not be the same experience with every program. Other programs can break the link by saving to a new temporary file and replacing the original, leaving the two names attached to different files.

If you use a different app, run the fsutil hardlink list command and confirm that both paths still appear.

Delete a name, keep the data

I deleted the file I called “original” and lost nothing

Here was the point I thought I might break it. I deleted the first file I created, original.txt. When I opened second-name.txt, nothing had changed. Even my most recent edits were still reflected.

However, when I deleted second-name.txt, both file names were now gone. This was reflected in my 1GiB test: the available space on my C: drive barely changed after I deleted the first name, but I got back about 1GiB after deleting the last name. As long as the name pointed to it, the data remained available on my computer.

Filenames on Windows are directory entries for specific files, and the data exists separately. When you delete one hard link, you have simply removed the label, but the shared data remains accessible through the remaining link.

Every file on your computer has a name which is already one directory entry for its data. Using the mklink /H command allows you to add a second name. Even though I called one file original.txt, it really doesn’t matter because neither name was ever more original than the other.

I came out with two practical realizations. As long as a hard link exists, you don’t reclaim any space that the data holds by deleting a name that points to it. Only removing the last link will free up space. Secondly, a hard link should not be mistaken for a backup; both names access the same data. Any change made through one name appears through the other.

My C: to D: attempt, and what to use when you need to cross drives

I wasn’t done just yet. I tried to link a file across drives, and Windows outright refused the operation: “The system cannot move the file to a different disk drive.” It’s also impossible to hard-link a folder or create a hard link across drives. For folders or files on different drives, I’d consider two other options:

A hard link is the way to go on the same drive if you want a real second name for a file. When linking across drives or to folders, use a symbolic link.