This is an attempt to avoid errors like "System.Exception : The previous
backup has time 9/27/2020 5:25:56 PM, but this backup has time 9/27/2020
5:25:55 PM. Something is wrong with the clock." We are seeing these
errors often recently in AppVeyor.
Replace `VerifyDir` and `CompareFiles` with
`AssertDirectoryTreesAreEquivalent` and `AssertFilesAreEqual`.
Move `WriteFile` to `TestUtils`.
Add "Symlink" category to start.sh.
This adds a basic symlink policy test that performs backups using each
symlink policy.
If you don't have the required privilege in Windows, you can get an
exception trying to create a symbolic link. If an exception is thrown
trying to create a symbolic link, the exception is trapped and the
test is marked as "Ignored"; e.g.,
```
1) Ignored : Duplicati.UnitTest.SymLinkTests.SymLinkPolicy
Client could not create a symbolic link. Error reported: (1314) A required privilege is not held by the client. | Read: [C:\td\backup-data\target] | Write: [C:\td\backup-data\symlink]
```
This allows us to simplify the ProblematicPathTests because the test
teardown methods can now handle deleting directories containing
problematic paths.
Change Duplicati.UnitTest.CommandLineOperationsTests to use `Setup()`
instead of `OneTimeSetUp()` to make sure the test files are in place
for each test.
This fixes#4273.
Change SystemIOWindows.PathGetFullPath() to convert forward
slashes to backslashes.
Change Duplicati.UnitTest.BasicSetupHelper.ZipFileExtractToDirectory()
to rely on slash fix-ups.
Even in .NET 4.6.2
`System.IO.Compression.ZipFile.ExtractToDirectory()` cannot handle
long paths. Replace call to
`System.IO.Compression.ZipFile.ExtractToDirectory()` with an
equivalent that extracts files to a temporary location and uses I/O
functions that support long paths to move them to their final
location.
In CommandLineOperationsTests.cs, use ISystemIO functions to handle
potentially long paths.
Add a fix to RecoveryTool for long paths that was missed by #4258.
This fixes#3863.
This updates all projects to target .NET Framework 4.7.1. The
TencentCOS and Tardigrade backends depend on .NET Standard 2.0. When a
.NET Framework prior to 4.7.1 is targeted, the system cannot be sure
that all the dependencies exist, so it copies all dependent assemblies
to the output directory. This causes many assemblies from the System
namespace to become bundled in the release.
https://stackoverflow.com/a/48875007
We had previously attempted to make individual projects target 4.7.1
(see pull request #4242), but this can cause compatibility issues when
4.6.2 projects depend on 4.7.1. projects.
This will require Mono 5.10.0 or greater (previously, we required 5.0.0
or greater).
https://www.mono-project.com/docs/about-mono/releases/5.10.0/#class-libraries
This fixes issue #4234.
Allow historically problematic Windows paths (i.e., files or
directories that end in a dot or a space) to be backed up with
Duplicati in Windows.
This fixes#3839.
Kenneth Hsu