backup failed: readlink: Unsuppotted reparse point type - How to provide some helpful info to troubleshoot?

[rnwolf]

Hi

I thought I'd give Vykar(0.14.1) a test run on my local Ubuntu home server. Installed the server, and then used the vykar-gui on a Windows 11, computer to perform a backup.
After about 5 minutes of updates on the GUI I got the following message "backup failed: readlink: Unsupported reparse point type"

I re-ran the backup from the command line:

==> Starting backup
 WARN xattrs requested but not supported on this platform; continuing without xattrs
 WARN recovered pending index entries from interrupted sessions recovered_chunks=249037 journals=1
 WARN saving progress for next run…
Files: 525374, Original: 10.76 GiB, Compressed: 5.06 GiB, Deduplicated: 0 B, Current: mailcow-hetzner-ansible-main/.git/refs/remotes/origin/main
Error: readlink: Unsupported reparse point type
==> Starting prune
==> Starting compact
==> Starting check
Check complete: 0 snapshots, 0 items, 0 packs existence-checked (0 chunks), 0 chunks data-verified, 0 errors

=== Summary ===
  backup       FAILED: readlink: Unsupported reparse point type
  prune        skipped (no retention rules)
  compact      skipped (backup failed)
  check        ok
  Duration:    4m 55s
Error: one or more steps failed

How do I diagnose the details, and provide some helpful info to troubleshoot?

[m3nu]

Thanks for reporting. This could be useful. I'll look into it. It's probably Windows-specific.

[m3nu]

Fix landed on main in f9d4f07 — will ship in the next release.

What changed:

• Walks no longer abort on unsupported Windows reparse tags (OneDrive Cloud Files placeholders, AppExecLink, dedup, HSM). They're skipped and counted as a soft error, same as a PermissionDenied file.
• File open/read/fstat against cloud placeholders that the provider can't materialize (ERROR_CANT_ACCESS_FILE 1920, ERROR_CLOUD_FILE_* 362/395/404) are skipped the same way.
• Every soft skip now surfaces a path-bearing warning to the CLI/GUI: skipping entry '<path>': <reason>. Hard readlink failures that still abort the backup now name the offending path in the error message, so you can pinpoint the problem file even in the failure case.

If you hit a related cloud-provider error code that isn't in the list above (362/395/404/1920), please reopen with the exact raw_os_error and we'll add it.