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.
In Duplicati.CommandLine.RecoveryTool, the `index` and `list` commands
do not recognize Duplicati backup files when those files are in paths
containing dashes.
For example, without this change, if you call
```
Duplicati.CommandLine.RecoveryTool index C:\Temp\duplicati-tests\recovery-tool\backup-files
```
the Duplicati backup files are displayed, but the recovery tool
reports "Not a Duplicati file, ignoring" for each of them.
Change "Duplicati.CommandLine.RecoveryTool restore" to support
restoring long paths, and files and directories that end in a dot or a
space when run on Windows.
Performance is greatly improved if we can create the index in memory.
We preserve the ability to create the index using files for recovery in
low resource environments.
- no code changes except those noted below
- projects upgrade to 4.6.2
- wixinstaller project upgraded automatically by VisualStudio
- wixinstaller updated to require 4.6.2
- Library.Encryption changed to Standard2.0 so accommodate update to SharpAesCrypt
After we removed the tilde expansion in revision c9aa6cf5fb ("Avoid
performing tilde expansion"), the Utility.ExpandEnvironmentVariables
method simply called System.Environment.ExpandEnvironmentVariables. We
can simplify the code by just referencing the built-in method directly.
Using strong-named assemblies can cause difficulties with the GNU LGPL
license, which allows for one to recombine or relink their application
with modified versions of the code. While one solution is to share the
private key so that people can sign the assemblies themselves, this
would break the trust that is expected from signed assemblies. For now,
the easiest fix is to simply not sign the assemblies. Note that by
doing so, we prevent the code from being referenced from other signed
assemblies.
This also fixes an issue introduced in revision ba94d36a80 ("Added
auto-update for WindowsService and Service."), where the WindowsService
project (signed) referenced the AutoUpdater project (not signed).
We also removed instances of <SignAssembly>false</SignAssembly> to be
consistent with newly created .csproj files that do not contain the
SignAssembly element.
This was motivated by the discussion in issue #2814.
