What a Windows file copy can miss: alternate data streams, links, placeholders and long paths

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

Most people picture a file as a name and a block of contents. NTFS allows a good deal more. A single file can hold several independent streams of data. A folder can be a pointer to another folder on a different volume. A document in a synchronised folder can be a placeholder with almost nothing stored locally. A path can be longer than older programs can open.

A file-level backup walks the folder tree and copies what it finds. Each of these structures gives it a decision to make: copy the extra data or skip it, follow the link or record it, download the placeholder or store the stub, open the long path or fail on it. Different tools decide differently, and some decide silently.

This guide works through each structure from Microsoft's documentation, shows how to find them with read-only commands, and sets out a restore test that would expose a tool that gets them wrong. It is about file-by-file backup of physical servers and file shares. Image-level backup reads disk blocks rather than walking files, so most of these questions do not arise in the same form (our understanding).

Why it matters

Each structure can make a restore look correct while being wrong in a way nobody notices for weeks:

• A dropped stream loses data that never appeared in Explorer, so no user reports it until an application that relies on it misbehaves.
• A followed link can copy the same data twice, or pull in a whole volume that was never meant to be in the job, or loop.
• A recorded link restores correctly only if its target also comes back.
• A placeholder backed up as a stub restores a file with no contents.
• A long path that the tool cannot open is skipped, and if the skip is logged as a warning rather than an error, the job still reports success.

None of these is exotic on a server that has hosted user shares, development tools or synchronised folders for a few years (our reading).

How it works

Alternate data streams

Microsoft's definition is short: "A stream is a sequence of bytes." Every file has a default data stream that holds what people think of as the file's contents. Microsoft notes that "By default, the default data stream is unnamed." A file can also carry any number of named streams, addressed as filename:streamname. Explorer and most programs show only the default stream, and the file size shown is the default stream's size.

Two details from the documentation matter for backup:

• "Each stream also maintains its own state for compression, encryption, and sparseness." A tool that copies streams has to handle each one's attributes, not just the file's.
• "There are no file times associated with a stream. The file times for a file are updated when any stream in a file is updated." A change to a named stream changes the file's modified time, so a backup that selects files by date will pick the file up, but a tool that then copies only the default stream will copy unchanged contents and miss the change it was triggered by (our reading).

The same page lists the stream types NTFS uses internally. One example is relevant to backup: EFS keeps its encryption data in a stream of type $LOGGED_UTILITY_STREAM, which is one reason encrypted files need their own backup path.

Reparse points

Microsoft describes a reparse point as "a collection of user-defined data" stored on a file or directory together with a tag that identifies its owner. When the file system opens the object, a filter driver that understands the tag decides what happens. Reparse points implement several things a backup tool meets on ordinary servers: junctions, symbolic links, mounted folders, and the stubs used by hierarchical storage, which the documentation illustrates with Microsoft's Remote Storage Server moving rarely used files to tape or optical media.

Microsoft's guidance to developers is explicit: "Backup applications that use file streams should specify BACKUP_REPARSE_DATA in the WIN32_STREAM_ID structure when backing up files with reparse points." In other words, the reparse data itself should be backed up, so that the link or stub is recreated on restore rather than replaced by a copy of whatever it pointed to. The same page adds that "Most applications should take special actions for files that have been moved to long-term storage", because opening such a file may trigger a slow recall.

Some limits are worth knowing because a restore can trip over them. Reparse point data cannot exceed 16 kilobytes. "There is a limit of 63 reparse points on any given path," which can drop to 31 when the reparse point targets a fully qualified path. "Reparse points and extended attributes are mutually exclusive." A restore that tries to apply both to one object will fail on one of them (our reading).

Hard links, junctions and symbolic links

NTFS supports three kinds of link, and they behave differently enough that a backup tool has to tell them apart.

A hard link is a second name for the same file. Microsoft's page says "Hard links can't reference directories, only files, and they can't reference files on different volumes." Both names are equal; neither is the original. A tool that walks the tree sees two files. If it stores both as independent copies, the restore produces two separate files where there was one, which uses more space and breaks anything that relied on a change through one name appearing at the other (our understanding).

A junction links a directory to another directory. "A junction can also link directories located on different local volumes on the same computer." Junctions are implemented as reparse points. A tool that follows a junction copies the target's contents under the junction's name. If the target is already in the job, it is copied twice; if the target is a large volume outside the job, the backup can grow unexpectedly; and if a junction points to one of its own parent folders, a naive walk loops.

A symbolic link can point to a file or directory, on the same volume or elsewhere (our understanding). Microsoft notes that "Symbolic links are transparent to users; the links appear as normal files or directories". That transparency is exactly what makes them easy for a backup tool to follow without meaning to.

Windows itself creates junctions in user profiles for compatibility with older folder names, and many applications create their own. Development tools, package managers and some database layouts use symbolic links heavily (our understanding).

Cloud placeholders

Synchronisation clients built on the Windows Cloud Files API can leave files on disk as placeholders. Microsoft describes placeholder files as able to "consume only 1 KB of storage for the filesystem header", and as "An empty representation of the file and only available if the sync service is available." When an application opens one, the file will "automatically hydrate into full files under normal use conditions", meaning the client downloads the contents.

For backup this creates a choice with no free option (our reading):

• A tool that opens every placeholder triggers a download of every file. On a large synchronised folder that can mean a very long job, heavy internet use and full local disk usage.
• A tool that skips placeholders or stores only the stub produces a backup in which those files have no contents. The restore brings back names and icons, and the data is still only in the cloud service.

Whichever the tool does, the backup record should say so. A folder that is mostly placeholders is better protected by backing up the cloud service directly than by backing up the stubs on one machine (our recommendation).

Long paths

In the classic Windows API, the maximum path length is MAX_PATH, "which is defined as 260 characters". Extended-length paths using the \\?\ prefix allow "a maximum total path length of 32,767 characters". Since Windows 10 version 1607, many file functions can drop the old limit, but Microsoft is clear that "your app must opt-in to the new behavior": a registry value or policy must be set, and the application itself must declare that it is long-path aware. The documentation warns, "This isn't a change that will affect all applications."

Two further points matter for restores. Microsoft notes that "It is possible to create a path with the Windows API that the shell user interface is not able to interpret properly." And a path that fits on the original server can become too long on restore if it is restored under a deeper folder, such as D:\Restore\2026-11-14\ServerName\ in front of the original path (our reading).

What the copying tools document

Robocopy is a useful reference point because its documentation is precise about what each option does, and many scripted file backups use it.

The documentation also notes that "The X flag is ignored if either /B or /ZB is used." So a script that tries to skip streams in backup mode will copy them anyway.

For programs that use the Windows backup API directly, BackupRead returns a file's data as a sequence of streams, each described by a WIN32_STREAM_ID header. The documentation states that "The SACLs are not read unless the file handle was created with the ACCESS_SYSTEM_SECURITY access right", and that "This function is not intended for use in backing up files encrypted under the Encrypted File System." Encrypted files need ReadEncryptedFileRaw instead. A tool built on BackupRead and BackupWrite can, in principle, capture every stream and the reparse data, but whether a particular product does is a question for its vendor.

Finding these structures on a file server

The listing examples below read the selected files. Any optional log output writes a separate file. They are documentation-based examples, not lab-validated commands; review paths and permissions before use and start with a small sample.

Alternate data streams. In Command Prompt (cmd.exe), the dir command's /r switch will "Display alternate data streams of the file". This is a non-recursive sample of one directory:

dir /r D:\Shares\Finance

In PowerShell 7.2 or later on Windows, Get-Item accepts a -Stream parameter for files and directories; Microsoft notes "To get all streams, use an asterisk". This is also a non-recursive sample, not a share-wide inventory. -Stream was introduced for files in PowerShell 3.0; directory-stream support starts at 7.2:

Get-Item -Path D:\Shares\Finance\* -Stream *

Every file downloaded from the internet in a browser usually carries a small Zone.Identifier stream (our understanding). Those are expected. Look for large named streams or streams on files that should not have them.

Reparse points, junctions and symbolic links. In Command Prompt (cmd.exe), the dir attribute filter /a:l lists reparse points (the documentation lists "l - Reparse points"); /s requests subdirectories. Do not paste these dir switches into PowerShell, where dir is ordinarily an alias for Get-ChildItem:

dir /a:l /s D:\Shares

For one object, fsutil reparsepoint query shows its tag and data:

fsutil reparsepoint query "D:\Shares\Projects\Archive"

Use only the query form. The same command also has a delete form, and Microsoft notes it is "typically used by support professionals".

Long paths. A Robocopy list-only run with /l lists files without copying, deleting or timestamping them. It does not itself create a log. Explicit output redirection or /LOG:<logfile> writes an output file; /LOG overwrites the named log, so select a dedicated audit path. Search the listing for long names. Alternatively, a PowerShell listing can report the longest full paths. In either case, add the length of the folder you would restore into.

Placeholders. Explorer shows the cloud state in the status column. For a scripted count, the file attributes on placeholders differ from fully local files (our understanding; the attribute names should be confirmed against the sync client's documentation before you rely on a script).

A restore test that would expose problems

This is a proposed, unvalidated exercise for an authorised isolated lab, using synthetic data and a separate test backup job configured to match the relevant production settings (our recommendation). Keep the source, every link target and separate restore destinations inside that lab. Obtain qualified human review before adapting the exercise to a production job. The synthetic folder should contain:

1. A text file with a named stream written to it, and a second file with a large named stream.
2. Two hard links to the same file.
3. A junction to a synthetic folder inside the test folder, and one to a synthetic folder outside that tree but still inside the isolated lab; neither may reference unrelated or production data.
4. A symbolic link to a file and one to a folder.
5. A file at a path of about 300 characters.
6. If synchronisation clients are in use, a placeholder that has never been opened and a file pinned as always available.
7. A file with restrictive permissions, including an audit entry if you rely on auditing.

After the restore, check each item: do the streams exist and match in size and byte contents or hashes; are the hard links still one file with two names or two separate files; were the junctions and links recreated as links, or replaced by copies; did the long path restore at all, and did the log say so; what did the placeholder become; are the permissions and audit entries intact. Record the answers as the behaviour of that tool and version, and repeat the test after upgrades.

Worked example (illustrative)

The following is invented to show the pattern. An accounting firm moves its file server to new hardware and restores the shares from the nightly file-level backup. The job had reported success every night.

A week later, staff find that a reporting add-in has lost its saved settings. The add-in stored its configuration in a named stream on each workbook. The backup tool copied default streams only, and the logs did not mention it.

At the same time, the restored server is using more disk space than the old one. A folder of shared templates had been linked into each department's share with junctions. The tool followed them and restored a full copy into every department.

A test restore of a prepared folder before the migration could have exposed both behaviours. In this example, the original server remains intact and still holds the named-stream settings. The firm reconfigures the tool to record links and copy streams, takes a new backup from that intact source, verifies that the new recovery point contains the named streams, then restores that new recovery point and checks the contents and link relationships. The old backup cannot supply bytes it never captured. If the source were gone, the omitted settings would need another surviving copy or reconstruction. The firm adds an isolated synthetic restore test to its monthly checks.

Risks and limits

• This guide relies on Microsoft's documentation. It does not describe how any particular third-party backup product handles these structures; that varies by product and version.
• Recording a junction or symbolic link rather than following it is only correct if the target is also backed up, or deliberately excluded and documented.
• Following links can be the right choice for a specific folder. The point is to decide, not to inherit a default.
• Hydrating placeholders during a backup can exhaust disk space or bandwidth. Agree how synchronised folders are protected before changing a tool's behaviour.
• Restoring to a different file system, such as a NAS share or a Linux server, can lose streams, links and some attributes even if the backup captured them, because the destination may not support them (our understanding).
• The restore test above checks one tool on one day. Products change; repeat it after upgrades.

Sources

All accessed 14 November 2026.

• Microsoft Learn, File Streams (Local File Systems): https://learn.microsoft.com/en-us/windows/win32/fileio/file-streams
• Microsoft Learn, Reparse Points: https://learn.microsoft.com/en-us/windows/win32/fileio/reparse-points
• Microsoft Learn, Reparse Points and File Operations: https://learn.microsoft.com/en-us/windows/win32/fileio/reparse-points-and-file-operations
• Microsoft Learn, Maximum Path Length Limitation: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
• Microsoft Learn, BackupRead function: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-backupread
• Microsoft Learn, Backup Functions: https://learn.microsoft.com/en-us/windows/win32/backup/backup-functions
• Microsoft Learn, Hard Links and Junctions: https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions
• Microsoft Learn, Symbolic Links: https://learn.microsoft.com/en-us/windows/win32/fileio/symbolic-links
• Microsoft Learn, Build a Cloud Sync Engine that Supports Placeholder Files: https://learn.microsoft.com/en-us/windows/win32/cfapi/build-a-cloud-file-sync-engine
• Microsoft Learn, robocopy: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy
• Microsoft Learn, dir: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dir
• Microsoft Learn, fsutil reparsepoint: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-reparsepoint
• Microsoft Learn, Get-Item: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-item

Related future topics

• Backing up and restoring EFS-encrypted files and the recovery agent certificate
• Restoring a Windows user profile: what file restores do not bring back
• Building a recovery inventory for a mixed Windows, Linux, Mac and NAS estate

This article was originally published on 14 November 2026.