STATUS_IO_REPARSE_TAG_MISMATCH (0xC0000277) on NTFS Drives

You're copying files, running a backup, or just opening a folder, and Windows throws STATUS_IO_REPARSE_TAG_MISMATCH (0xC0000277). Translation: something on that volume claims to be a reparse point (symlink, junction, mount point, OneDrive placeholder, dedup stub), but the tag in the file record doesn't match the tag the I/O manager expected. The file system is lying to itself.

The culprit here is almost always a third-party tool that rewrote the reparse tag without updating the matching data structure. In practice I see this after three things: restoring an image with a backup tool that doesn't understand Microsoft's reparse tags (Acronis, older Macrium builds, Veeam agent with dedup on), OneDrive or Dropbox sync recreating placeholders on a volume with a different tag scheme, and Data Deduplication re-optimizing files on a volume that wasn't originally dedup-enabled.

Work down this list. Stop as soon as your file operation succeeds.

Fix 1 — The 30-second sanity check

Before you touch anything, confirm the error is actually about a reparse point and not a disk failing underneath. The two look identical to users and completely different to fsutil.

1. Open an elevated Command Prompt.
2. Find the file the error complains about. If the error dialog doesn't name it, check Event Viewer → Windows Logs → System for a source of Ntfs or Disk around the timestamp.
3. Run:

fsutil reparsepoint query "C:\path\to\offending\file"

Two outcomes:

• It prints a tag and some hex. Good, it's a real reparse point. Move to Fix 2.
• It says "The file or directory is not a reparse point." Then the file record is corrupt, not just the tag. Go straight to Fix 3.

If the drive is making clicking noises or SMART is yellow, stop. This isn't your error. Replace the disk.

Fix 2 — The 5-minute fix: clear the bad reparse point

If it's a data file or folder you can recreate, just delete the reparse point. This is the fix nobody wants to hear, but it's the fastest path when the underlying data isn't critical.

First, identify the tag. Common ones you'll see printed by fsutil:

If it's a Store app link or a dedup stub, don't delete it manually — you'll break the app or the volume. Skip to Fix 3. If it's a junction or symlink you created, nuke it and recreate:

rmdir "C:\path\to\badlink"
mklink /J "C:\path\to\badlink" "D:\real\target"

For OneDrive/Dropbox placeholders, the fastest reliable fix is to unlink the folder from the sync client, delete the local placeholder cache, and re-sync. Right-click the OneDrive icon → Settings → Account → Unlink this PC. Delete the folder. Re-link. Re-download. It's tedious, but I've never seen a manual tag edit survive a sync cycle anyway.

Fix 3 — The 15-minute fix: chkdsk with reparse awareness

When the whole volume is throwing 0xC0000277 across multiple files, this is corruption at the NTFS metadata level. chkdsk is the only tool that touches that layer.

Back up first. /f and /r can make a marginal drive worse. If SMART is clean and the data matters, clone the volume before you run this.

Run it in this order:

1. Read-only pass first — see how bad it is:

chkdsk C: /scan

Look for lines mentioning "reparse" or "corrupt file record segment." A handful of orphaned reparse points is normal after a bad restore. Hundreds means the backup tool wrote garbage.

2. If /scan found problems, run the offline fix. Schedule it and reboot:

chkdsk C: /f /r /x

/f fixes errors, /r locates bad sectors and recovers readable info, /x forces the volume to dismount first. On a boot volume this schedules the check on next restart. On a multi-TB drive, expect it to run for hours — that's normal, don't interrupt it.

What chkdsk does here is rebuild the reparse point from the file record's underlying data. If the tag and the data structure both exist but disagree, it picks one and moves on. If the data structure is gone entirely, it may convert the file to a normal file — losing the link but keeping the target.

Fix 4 — The nuclear option: delete the corrupt record with fsutil

Sometimes chkdsk can't repair a reparse point because the tag itself is garbage — not a known value, just random bytes. This happens after a bad sector hit a file record, or after a backup tool wrote a non-standard tag (I've seen this with really old Symantec Backup Exec restores onto Server 2016+ volumes).

You can force-remove the reparse data without deleting the file:

fsutil reparsepoint delete "C:\path\to\file"

On a healthy file this just removes the link and leaves the data. On a broken one, it clears the bad tag so the file becomes a normal file again. Then you can move, copy, or delete it like a regular file.

If fsutil reparsepoint delete itself errors out with 0xC0000277, you're at the point where only chkdsk /f (already run) or restoring the file from backup will help. Don't spend an hour trying to hex-edit the MFT by hand — the ROI isn't there.

What actually prevents this

Three things, in order of impact:

• Use backup tools that are reparse-aware. Veeam, newer Macrium, and Windows Server Backup handle these correctly. Tools from before 2015 often don't. If your backup tool has a "preserve reparse points" option, turn it on.
• Don't move dedup-enabled volumes between servers without re-running dedup optimization. The stubs don't travel well.
• Disable cloud placeholder sync on volumes that also host junctions or mount points. OneDrive and Dropbox both rewrite reparse tags on scan, and they don't check what was there before. If a folder is a mount point to another drive, exclude it from sync.

One more thing: if you're seeing this on every file in a folder after a restore, don't fix files one at a time. Restore the folder again with a different tool. You'll save hours.