No. Inodes — or MFT entries, which is what NTFS uses in their place — are filesystem-internal records and are never copied between drives. Every copy creates a brand-new file at the destination, and whether names that shared one file on the source end up sharing one file there depends entirely on the copy tool. Windows Explorer drag-and-drop, copy, and xcopy do not recreate hard links, so linked files arrive as independent duplicates.
What a drive-to-drive copy actually does
Copying a file between volumes does three things: the tool creates a new, empty file at the destination, streams the source contents into it chunk by chunk, and migrates the few metadata items it knows how to translate, such as modification timestamps or NTFS security descriptors. That is the whole transaction.
The source file's MFT entry — the record holding its size, timestamps, and list of names — stays put; the destination file gets a freshly allocated one. That is unavoidable, because an MFT entry belongs to one volume's master file table. (Not every filesystem even has inodes: FAT has none, and NTFS entries play a similar but not identical role.) So the real question is not "do the inodes get copied?" but "does the tool notice that several names pointed at one file, and rebuild that arrangement?"
Hard links are extra names, not separate objects
A hard link is simply an additional name registered to the same underlying file, and NTFS keeps all of a file's names in its MFT entry. A link-aware tool must therefore notice that a file's link count exceeds one, remember which source names resolve to the same file, copy the data once, and call CreateHardLink to attach the remaining names to the new copy. When this works, every destination name attaches to the new copy's fresh MFT entry — exactly the outcome you would want. Tools that skip this logic treat every name as an independent file and duplicate the data.
Drag-and-drop results, and partial copies
Drag a set of hard-linked files to another drive in Explorer and each name is copied independently. The result is ordinary, unlinked duplicates: every file opens fine and contains all of its data, and nothing is "broken," because a hard link is not a pointer object the way a symlink is. The only cost is disk space, since storage that was shared is now spent once per name.
Partial copies are equally uneventful. Hard links have no source, destination, or "original" that the others depend on. If five names point to one file and you copy just one, you get one complete, self-sufficient file, and the other four keep working on the source exactly as before.
The OneDrive case
The OneDrive folder on your machine is an ordinary NTFS folder, so its files live on the same filesystem as everything else. But the cloud copy is a separate filesystem maintained by sync software, and that sync does not carry hard-link relationships across: two locally linked files arrive on another PC as two unrelated files. OneDrive also uses NTFS reparse points — the same mechanism behind symlinks and junctions — for its on-demand files that download only when opened. Layering your own links inside a sync-managed reparse-point tree is fragile, so assume hard-link metadata is lost in any cloud round trip.
How to preserve hard links, and verify them
Since ordinary copy paths won't do it, use a link-aware tool or a small script. Robocopy is designed to detect hard-linked files during a tree copy and recreate the links at the destination, making it the simplest built-in option — but verify the result rather than trusting any tool blindly. A script is straightforward in principle: enumerate the files, group them by file ID, copy each group once, then call CreateHardLink for the remaining names.
To check whether links survived, ask NTFS directly:
fsutil hardlink list C:\source\report.datThis prints every name registered to that file. Run it on the source before copying and on the destination afterwards; a single line where the source showed several means the links were not recreated.
Before converting symlinks to hard links, note two limits. A hard link cannot cross volumes, so any symlink pointing to another drive cannot be converted. And hard links cannot reference directories: folder symlinks would have to become junctions, which are also reparse points and hit the same copy problem. Rehearse on a small test folder and confirm the link structure before committing the whole library.
Frequently Asked Questions
Does NTFS have inodes?
Not in the Linux sense. NTFS stores a file's metadata and its list of names in an MFT entry, which plays a similar role but is structured differently. Either way, these records belong to one volume and are never transferred by a copy.
If a tool ignores hard links, do I lose anything?
No data is lost. Each name becomes a complete, independent copy; the only cost is the extra disk space from storing shared data once per name.
Can I rebuild hard links after a copy flattened them?
Yes, if you know which names should share data. In a Command Prompt, delete the duplicate and recreate it as a link to the surviving copy:
mklink /H "D:\backup\copy.txt" "D:\backup\original.txt"Doing this across a large tree by hand is tedious, which is why a link-aware copy is preferable.
Can hard links span two drives?
No. All names must live on the same volume. Cross-volume references require symlinks or junctions, which are reparse points and need link-aware copying.
How do I count the names pointing to one file?
Run fsutil hardlink list with the file's path. Each line printed is one name registered to that same file; a single line means the file currently has no extra links.