Your File Copied to the Cloud — but Did Its Hard Links, Sparse Layout and Hidden NTFS Streams Survive?

Short answer: not necessarily. A normal cloud sync client is usually excellent at moving the visible content of ordinary files, but some local filesystems carry structure that is not represented by ordinary filename + bytes + timestamps alone.

Three examples matter more than they first appear:

• hard links — multiple directory entries that refer to the same underlying file;
• sparse files — logically large files whose zero-filled regions may consume almost no physical disk blocks;
• NTFS alternate data streams (ADS) — additional named byte streams attached to one Windows file besides the normal unnamed stream.

A cloud service can successfully upload what looks like archive.bin and still fail to preserve one or more of those filesystem semantics when you download it again.

That is why the useful question is not:

“Did the file upload?”

It is:

“What filesystem relationships and side streams must still exist after a clean restore?”

These are not three versions of the same problem

They fail differently, so test them separately.

Microsoft's NTFS documentation makes the distinction concrete. A hard link is another directory entry to the same file. If one hard link modifies the file, the other names see the same underlying change. A sparse file can report a very large logical size while only non-zero regions consume physical allocation. NTFS file streams can attach additional named byte streams to one file.

Those are filesystem-native concepts. They are not automatically the same thing as a cloud provider's object model.

Hard links: two names, one underlying object

Consider this local NTFS or POSIX structure:

``text /project/current.bin /project/archive/current.bin ``

Suppose those two paths are hard links to the same underlying file.

Locally:

• editing either name edits the same underlying data;
• deleting one name does not remove the data while another hard link remains;
• the apparent total size of both names can overstate actual physical disk consumption.

A naïve cloud restore can turn that into:

``text /project/current.bin -> independent object A /project/archive/current.bin -> independent object B ``

The visible bytes may initially be identical, but the link relationship is gone.

From that point on, editing one restored path no longer updates the other.

That is a semantic loss even though no content hash failed.

Dropbox gives unusually direct evidence: hardlinks and other NTFS links are not synced

Dropbox's current Windows sync-icon documentation explicitly says a folder can continue showing the syncing indicator when it contains symlinks, hardlinks or other NTFS links, because those links themselves are not synced.

That is stronger evidence than a vague “some metadata may not be supported” statement.

For Dropbox, the safe conclusion is:

Do not use an ordinary Dropbox round trip as a hard-link-preserving filesystem backup.

Dropbox can still preserve the visible file data that sits behind a supported path. But if your restore requirement includes “these two paths must still be hard links to one inode/file record,” the documented consumer sync behavior is not that contract.

Dropbox also publishes a separate extended-attributes support list. That list includes specific metadata transported through filesystem-visible attributes, including selected Windows Alternate Data Streams used by Dropbox itself and several macOS/POSIX attributes.

The important word is selected.

Dropbox does not say:

“Every arbitrary NTFS named stream will be preserved forever.”

Its documentation lists the streams and attributes it supports. Treat that list as a whitelist-style contract, not proof that arbitrary filesystem side data is a generic cloud primitive.

OneDrive: cloud file sync is not an NTFS image format

Microsoft's OneDrive documentation clearly says the sync client does not support synchronizing through symbolic links or junction points and that network or mapped drives cannot be the OneDrive sync location.

Those restrictions already show that the OneDrive namespace is not a transparent clone of every Windows filesystem construct.

For hard-link identity, sparse allocation layout and arbitrary NTFS alternate streams, Microsoft's public consumer OneDrive documentation does not publish a general round-trip guarantee that says:

• two local hard links will download as the same hard-linked file record;
• a sparse file will retain exactly the same physical hole map after download;
• every named ADS will survive upload and restore.

That absence matters because the OneDrive web object has a different abstraction from an NTFS Master File Table record.

CloudScope therefore does not claim that OneDrive “deletes every hard link” or “always expands every sparse file.” Those would be broader claims than the public contract supports.

The safe engineering statement is:

If hard-link identity, sparseness or ADS preservation is a restore requirement, verify it independently. Do not infer it from OneDrive's green sync state.

Google Drive: one cloud file object is not a local inode graph

Google Drive's API represents stored binary content as a blob file with a Drive file ID and cloud metadata. Google also has explicit cloud-native shortcut objects.

That model is useful, but it is not documented as a representation of:

• local inode numbers;
• an NTFS hard-link count;
• a sparse-allocation map;
• arbitrary NTFS named data streams.

That distinction becomes important when a developer archives build trees, package caches, disk images or forensic datasets that use filesystem features more richly than an ordinary document folder.

A Drive upload can correctly preserve the main bytes of a file while the restored file is a newly created local filesystem object with a different allocation strategy and no original hard-link topology.

Again, this is not a criticism of Google Drive. It is a scope distinction.

Google Drive is a cloud file/object system. A local filesystem image is a different job.

iCloud / File Provider: explicit symlink and alias types still do not equal a hard-link contract

Apple's File Provider framework is more expressive than many people assume.

When a provider creates an item, Apple's template can identify the item as:

• a regular file;
• a directory;
• a symbolic link;
• an alias.

File Provider also gives items persistent identifiers and can carry selected filesystem metadata and extended attributes.

That is useful evidence that Apple treats some non-ordinary filesystem object types explicitly.

But a hard link is not the same thing as a symbolic link or alias. A hard link is another directory entry to the same underlying file object. The public File Provider material checked for this article does not provide a general consumer contract saying arbitrary local hard-link graphs, sparse allocation maps or NTFS ADS semantics round-trip through iCloud Drive unchanged.

So do not jump from:

“Apple supports symlink/alias item types”

to:

“Therefore every filesystem relationship is preserved.”

Those are different claims.

pCloud: file IDs are cloud object identity, not proof of local hard-link identity

pCloud's public API exposes a clear object model:

• a file has a fileid;
• it has one parent folder relation in returned metadata;
• it has cloud metadata such as size, created/modified time, hash and ownership/sharing flags.

That is useful cloud-object identity.

But the documented metadata structure does not expose a general filesystem field such as:

• NTFS hard-link count;
• POSIX inode identity;
• sparse extent map;
• arbitrary named NTFS stream collection.

That means CloudScope will not claim pCloud preserves those filesystem structures merely because the visible file uploads successfully.

pCloud can still be a perfectly reasonable target for portable archive artifacts. The distinction is that the artifact itself should encode the filesystem semantics you need, or your backup method should explicitly restore them.

Sparse files: the bytes can match while disk usage explodes

Sparse files create another type of false confidence.

Imagine a virtual-disk-style file with:

• logical size: 500 GB;
• physically allocated non-zero data: 35 GB.

The local filesystem can represent the remaining ranges as holes that read back as zeros.

If a migration path preserves only the logical byte sequence, the downloaded result could theoretically still hash to the same logical content while occupying far more physical space on the destination filesystem.

That means there are two separate verification questions:

1. Content verification — are the logical bytes identical?
2. Allocation verification — did the destination preserve sparse extents efficiently?

Ordinary checksums answer the first question, not the second.

For workloads with huge sparse images, both matter.

Do not estimate required restore disk space from the source's “size on disk” alone unless you know the destination workflow preserves sparseness.

NTFS alternate data streams: the visible file may not contain all the data

NTFS can attach additional named streams to a file.

For example, conceptually:

``text report.txt report.txt:classification report.txt:custom-metadata ``

The normal Explorer view may focus on the unnamed main stream, while the file still carries other named streams.

That makes ADS a classic migration trap.

A transfer tool that copies only the main stream can produce a destination file that:

• has the correct visible filename;
• has the correct visible text;
• has the expected main-stream checksum;
• but is still missing additional named streams.

This is why “the file opens” is not enough if ADS is part of the application's data model or compliance metadata.

Dropbox is the useful documented example: it supports specific filesystem-visible attributes and Windows ADS names, not an unlimited promise for every arbitrary stream.

For OneDrive, Google Drive, iCloud and pCloud, do not assume arbitrary ADS preservation without an explicit provider/tool contract and a restore test.

A hard-link test is easy — and far more useful than arguing from theory

If hard-link preservation matters, create a disposable test before migrating production data.

On a source filesystem that supports hard links

Create:

``text original.bin linked.bin ``

where both names point to the same underlying file.

Then record:

• file content hash;
• hard-link count or inode/file ID;
• both paths.

Sync/upload the test tree

Use the exact production path you intend to use:

• desktop sync;
• browser upload;
• provider API;
• migration tool.

Do not assume those paths behave identically.

Restore to a clean filesystem

Download to a new directory or second machine.

Then test:

• are both paths present?
• are their hashes identical?
• do they still share one file identity?
• if you modify one path, does the other reflect the same underlying change?

If the last two checks fail, you restored two copies, not a hard-link relationship.

A sparse-file test needs logical size and allocated size

For sparse data, record both:

• logical file length;
• physical blocks / allocated size.

After restoration, compare both again.

If the logical hash and length match but physical allocation is dramatically larger, the content survived but the sparse representation did not.

That may be acceptable for a small file. It can become operationally expensive for multi-hundred-gigabyte disk images.

ADS needs a stream inventory, not just a main-file hash

For NTFS ADS, inventory the streams before migration.

Your verification manifest should conceptually contain:

``text path | main stream hash | named streams | each stream size/hash ``

After restore, enumerate the destination streams again.

If your workflow cannot enumerate or restore those streams, then the migration contract does not include ADS — regardless of whether the ordinary file looked fine.

When should you package the data first?

Packaging can be useful when the destination cloud is good at storing ordinary blobs but the source tree contains richer filesystem structure.

Examples include:

• deployment trees with hard links;
• sparse VM/disk images;
• Windows datasets that rely on ADS;
• Linux trees where permissions, xattrs and links matter.

But the archive/backup format must itself support the exact metadata class you care about.

Do not assume every ZIP, TAR or copy tool preserves every feature by default.

The correct question is:

Can this archive or backup method round-trip the required feature on my source and destination filesystems?

Then test it.

The practical five-provider matrix

This table is intentionally conservative.

“No public guarantee verified” does not mean a provider destroys the feature in every possible case. It means you should not make that feature part of a recovery promise without testing the exact path.

The restore checklist that actually proves something

For filesystem-special data, use a two-layer verification plan.

Layer 1 — content

Verify:

• path exists;
• logical file size;
• checksum;
• expected file opens.

Layer 2 — filesystem semantics

Verify the relevant subset:

• hard-link identity/count;
• sparse allocation;
• named streams;
• executable bit;
• ACL;
• xattrs;
• owner/group;
• timestamps.

A green cloud sync icon proves neither layer completely by itself.

Final answer

If all you need is a portable PDF, JPEG, Office document, media file or archive blob, ordinary cloud storage is usually the right abstraction.

If the workload depends on hard links, sparse allocation, ADS, ACLs, xattrs or other filesystem-native semantics, ordinary sync is not automatically a filesystem backup.

The safest rule is:

Preserve the semantics in a format/tool that explicitly understands them, store the resulting artifact in cloud storage, then prove the restore on a clean target before retiring the source.

That is a much stronger recovery contract than “all filenames appeared online.”

Sources used for this article

• Microsoft Learn — fsutil hardlink: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-hardlink
• Microsoft Learn — Sparse Files: https://learn.microsoft.com/en-us/windows/win32/fileio/sparse-files
• Microsoft Learn — File Streams: https://learn.microsoft.com/en-us/windows/win32/fileio/file-streams
• Dropbox Help — Windows sync icons / hardlinks and NTFS links: https://help.dropbox.com/en-us/sync/sync-icons-windows
• Dropbox Help — Supported extended attributes: https://help.dropbox.com/sync/extended-attributes
• Microsoft Support — OneDrive restrictions and limitations: https://support.microsoft.com/en-US/onedrive/restrictions-and-limitations-in-onedrive-and-sharepoint
• Google Drive API — File resource / metadata: https://developers.google.com/workspace/drive/api/reference/rest/v3/files
• Apple Developer — File Provider create item semantics: https://developer.apple.com/documentation/fileprovider/nsfileproviderreplicatedextension/createitem
• pCloud Developers — Metadata structure: https://docs.pcloud.com/structures/metadata.html