* experimental faster db rebuild (#4955)
* try run update db query for every block file only when needed
add repair-force-block-use option
more appropriate naming for some routines
more tracing
more comments
The handling of relative paths in SystemIOWindows was broken by changes for #4256.
Change SystemIOWindows.PrefixWithUNC to only prefix paths with `\\?\` when they can be prefixed; i.e., only prefix paths that are fully qualified and that don't contain relative path components like `.` or `..`. This way, relative paths passed to SystemIOWindows methods work correctly again. Also support network paths specified using forward slashes; e.g., `//example.com/share/foo.txt`.
Simplify SystemIOWindows.GetFullPath since Path.GetFullPath will honor `\\?\` prefixes and can replace forward slashes with backslashes, etc.
Copy and adapt source for Path.IsPathFullyQualified from https://github.com/dotnet/runtime, which is MIT licensed.
Add unit test for Duplicati.CommandLine.BackendTool to validate the fix.
This fixes#4632.
Add Storj DCS backend and deprecated Tardigrade DCS backend.
Storj renamed their "Tardigrade Decentralized Cloud Storage" product to "Storj DCS". This adds a new Storj DCS backend and deprecates the old Tardigrade one. A warning is issued to inform Tardigrade users to modify their configurations to use the new backend.
This also adds a passphrase verification field to ensure that the user has provided the correct encryption passphrase.
The TLSharp library has some issues and the behavior of the Telegram
backend is not reliable.
Some alternative libraries for communicating with the Telegram API are
TgSharp, TDLib and TdSharp.
This fixes#4424.
Revert "Merge pull request #4324 from martikyan/feature/telegram_backend"
This reverts commit c7f9f8f556, reversing
changes made to 85139f86f2.
This is a defensive measure in case legacy path handling has been
enabled at the system level. Duplicati requires that legacy path
handling be _disabled_ to function properly.
Issue #4295 appears to be a result of legacy path handling being
enabled globally.
Change "find" and "restore" commands to not prefix `@` file filters
with `*` and to not suffix `@` folder filters with `*` since wildcards
cannot be used with `@` filters.
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.
Kenneth Skovhede