ts678
August 10, 2020, 2:14pm
4
For those who didn’t follow the “Exclude invalid Windows paths” link, that plan got superseded by a fix to tolerate such paths. The fix is in 2.0.5.109 Canary. It seems generally fine, but has one issue fixed so far.
duplicati:master ← dferreyra:support_problematic_windows_paths
opened 05:26AM - 18 Jul 20 UTC
Allow historically problematic Windows paths (i.e., files or
directories that e… nd in a dot or a space) to be backed up with
Duplicati in Windows.
This fixes #3839.
I've taken a stab at changing Duplicati to support files and directories that end in a dot or a space.
Just a quick recap of some things that weren't working in Duplicati under Windows as I tested out changes for #4251:
1. Paths that include directories that end in one or more spaces ("` `") or one or more dots ("`.`") can trigger a UNIQUE CONSTRAINT violation in Duplicati (and from reading #3839, other kinds of exceptions)
1. Files that end in one or more spaces ("` `") or one or more dots ("`.`") could appear to have been successfully backed up and you could even select the files during a restore, but the contents of those files never actually made it into the back up so they could not actually be restored
These kinds of files and directories trip up the AlphaFS library (and, historically, .NET). For example, this call
```cs
AlphaFS.Directory.GetDirectories(@"\\?\C:\Temp\dir.")
```
can trigger an exception about the path not being found, or, if a path without the trailing dot exists (e.g., plain "`C:\Temp\dir`"), it can silently send AlphaFS down into the wrong directory.
.NET 4.6.2 has added support for using the "`\\?\`" prefix, so long paths can now be handled with the native .NET functions. Plus the .NET 4.6.2 functions do not have problems with trailing dots and spaces.
I changed SystemIOWindows.cs to rely on the new behavior of .NET 4.6.2.
At this point, unit tests pass, I can back up combinations of directories and files that end in dots or spaces, I can continue to back up files with long paths, and everything successfully restores. I've also tried snapshot (VSS) backups against locked files, and I've tried backups of network shares (e.g., "`\\example.com\share\file.txt`").
I would like to know what else I should look at to make sure things are working -- I don't have a feel for how comprehensive the unit tests are in that regard. Also, I'm wondering if I should try creating unit tests for any of this.
As far as the source code changes themselves, I removed the uses of the `PathTooLong...()` wrappers. For calls where the "`prefixWithUnc`" parameter was true, I replaced them with calls to the native .NET functions where the path parameters are passed through `PrefixWithUNC()`. For example, this
```cs
public bool DirectoryExists(string path)
{
return PathTooLongFuncWrapper(System.IO.Directory.Exists,
Alphaleonis.Win32.Filesystem.Directory.Exists, path, true);
}
```
was replaced with
```cs
public bool DirectoryExists(string path)
{
return System.IO.Directory.Exists(PrefixWithUNC(path));
}
```
For calls where the "`prefixWithUnc`" parameter was false, I still want to protect each path with a UNC prefix. At the same time I want the return values to be UNC prefixed or not depending whether the given path was prefixed. So, for example, this
```cs
public string GetPathRoot(string path)
{
return PathTooLongFuncWrapper(Path.GetPathRoot, AlphaFS.Path.GetPathRoot, path, false);
}
```
was replaced with
```cs
public string GetPathRoot(string path)
{
if (IsPrefixedWithUNC(path))
{
return Path.GetPathRoot(path);
}
else
{
return StripUNCPrefix(Path.GetPathRoot(PrefixWithUNC(path)));
}
}
```
I also changed `StripUNCPrefix()` to correctly handle the "`\\?\UNC\`" case.
Release: 2.0.5.109 (canary) 2020-08-07
Improved handling of problematic filenames on Windows and increased test coverage, thanks @dferreyra
and the description of the found-and-fixed-in-next-Canary issue follows that. Eventually this will be in Beta.