VSS snapshot path translation produces invalid paths on Windows (2.4.0.0)

VSS snapshot path translation produces invalid paths on Windows (2.4.0.0)

Environment info

• Duplicati version: 2.4.0.0_stable_2026-09-03
• Operating system: Windows Server 2025 x64 (KVM/QEMU guest)
• Backend: file / local target (also reproduced with an encrypted remote target)
• Run mode: Duplicati.GUI.TrayIcon.exe, started by the built-in Administrator account with full administrative rights. No Duplicati service is installed. Also reproduced with Duplicati.CommandLine.exe from an elevated shell.
• Last known good version: the previously installed 2.3.x stable on the same machine, unchanged job configuration

Bug description

With --snapshot-policy=required, every backup fails immediately with an IOException. The snapshot itself appears to be created, but the source paths are translated to paths pointing at a volume that is not accessible. The drive letter of the source path is removed and no snapshot root is inserted in its place.

With --snapshot-policy=off the exact same job completes without any error.

Observed path translations

The pattern is consistent: the leading C: is stripped from the source path, the remaining string starts with a single backslash, and the Windows path helper then treats it as a UNC path and prefixes \\?\UNC. The expected snapshot device path (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyNN\...) never appears anywhere in the log.

With --vss-use-mapping=true the translation targets a drive letter instead, but that drive letter is never actually mounted, so the result is equally unusable.

Steps to reproduce

1. Create a backup job with a local source such as C:\Tools and any destination.
2. Run it with --snapshot-policy=off — completes successfully.
3. Run the same job with --snapshot-policy=required — fails immediately.
4. Repeat step 3 with --snapshot-provider=AlphaVSS and with --vss-use-mapping=true — fails in the same way, only the shape of the invalid path changes.

Command used for the isolated test:

Duplicati.CommandLine.exe backup "file://C:\temp\duptest" "C:\Tools" ^
  --no-encryption --snapshot-policy=required --snapshot-provider=AlphaVSS ^
  --log-file=C:\temp\dup-alpha.log --log-file-log-level=profiling

• Actual result: Fatal error => Der angegebene Pfadname ist ungültig. : '\\?\UNC\Tools\'. (The specified path name is invalid), 0 files examined.
• Expected result: source paths translated onto the shadow copy device and the backup completing as it does with snapshots disabled.

VSS on this machine is healthy

Creating a shadow copy manually succeeds:

$c = Get-CimClass Win32_ShadowCopy
Invoke-CimMethod -CimClass $c -MethodName Create -Arguments @{Volume="C:\"; Context="ClientAccessible"}
# ReturnValue: 0, ShadowID: {B2272694-B10F-4755-AECB-54E7123FF52A}

vssadmin list shadows then reports the shadow copy on \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy27, created by Microsoft Software Shadow Copy provider 1.0. vssadmin list writers reports all writers as stable with no errors. The system volume is NTFS.

A QEMU Guest Agent VSS Provider is registered on this machine. Its service was stopped for the tests and the failure is unchanged, so it does not appear to be involved.

The Visual C++ Redistributable x64 is installed (v14.51.36247.00).

Relevant log output

Without --vss-use-mapping (AlphaVSS provider, same with the default provider):

Failed to enumerate path: C:\Tools\ => Der angegebene Pfadname ist ungültig. : '\\?\UNC\Tools\'.
Fatal error => Der angegebene Pfadname ist ungültig. : '\\?\UNC\Tools\'.

System.IO.IOException: Der angegebene Pfadname ist ungültig. : '\\?\UNC\Tools\'.
   at System.IO.FileSystem.GetAttributeData(String fullPath, Boolean returnErrorOnNotFound)
   at System.IO.File.GetAttributes(String path)
   at Duplicati.Library.Common.IO.SystemIOWindows.GetFileAttributes(String path)
   at Duplicati.Library.Snapshots.WindowsSnapshot.GetAttributes(String localPath)
   at Duplicati.Library.Snapshots.SnapshotSourceFileEntry.get_Attributes()
   at Duplicati.Library.Snapshots.SnapshotSourceFileEntry.get_SymlinkTarget()
   at Duplicati.Library.Snapshots.SnapshotSourceFileEntry.get_IsSymlink()
   at Duplicati.Library.Main.Operation.Backup.MetadataPreProcess.ProcessMetadataAsync(...)

With --vss-use-mapping=true:

[Warning-...FileEnumerationProcess-PathProcessingErrorEnumerate]: Failed to enumerate path: C:\Tools\
System.IO.IOException: Der angegebene Pfadname ist ungültig. : '\\?\D:\Tools'.
   at System.IO.Enumeration.FileSystemEnumerator`1.Init()
   at System.IO.Enumeration.FileSystemEnumerableFactory.UserFiles(String directory, String expression, EnumerationOptions options)
   at System.IO.Directory.GetFiles(String path)
   at Duplicati.Library.Snapshots.WindowsSnapshot.ListFiles(String localFolderPath)
   at Duplicati.Library.Snapshots.SnapshotBase.EnumerateFilesystemEntries(ISourceProviderEntry source)+MoveNext()

A profiling-level log contains no snapshot creation or snapshot failure messages at all, which makes it hard to tell from the log alone whether the snapshot volume was successfully exposed.

Notes

Because the failure is identical across both snapshot providers and both mapping modes, and because WindowsSnapshot sits above the provider layer, the problem looks like it is in the path translation in WindowsSnapshot rather than in a specific VSS provider.

Two suggestions independent of the root cause:

1. If the snapshot root cannot be resolved, the backup should abort with a clear snapshot error instead of continuing with a path built from an empty root. The current failure mode reports a misleading "network path not found" / "invalid path name", which makes the cause very hard to find.
2. Logging the resolved snapshot root and the translated source paths at profiling level would make this class of problem diagnosable from the log.

Full profiling logs for both runs are available on request.