Change RestoreController.js to handle the case where the selected
restore paths contain literal wildcard characters. For files, prefix
with `@`. For directories, convert to regular expression filters so
that we can preserve the literal wildcard characters and also support
the equivalent of a globbing `*` suffix.
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.
Switch back to using `FilterType.Simple` for `@` filters to fix the
restore picker again.
In LocalDatabase.cs, replace code that was explicitly looking for the
presence of wildcard characters to instead trigger off of
`FilterType.Wildcard`. This fixes the "find" command.
Change FilterEntry.ToString() to prefix Simple filters with `@` so
that if simple filters with wildcard characters make the round-trip
through a string, their `FilterType.Simple` type is preserved.
Add new filter syntax, prefixing with an "at sign"; i.e., `@...`, that
disables glob expansion, treating `*` and `?` wildcard characters as
literal characters.
In the GUI, change the restore file picker to prefix paths with `@`
when expanding a node to avoid mistaking literal `*` or `?` characters
for wildcards characters and triggering the following error:
```
Filter for list-folder-contents must be a path prefix with no wildcards Parameter name: filter
```
This fixes#4300.
Tree changes in query
* Move inner selection S to a temporary table
* Reorder join field in outer query
* Remove intersection with File view in outer selection
File view is already intersected with in selection S
With the above-mentioned changes, on a specific testset, query took 9s instead of 6min.
Under Windows, strip paths of any `\\?\` prefix to prevent Duplicati
from storing paths prefixed with `\\?\`.
This fixes an inconsistency in the stored data where, if the user
provided a prefixed path to back up (e.g., `\\?\C:\Temp`), Duplicati
would store an entry with the prefixed path (e.g., `\\?\C:\Temp`)
along with entries with paths stripped of their prefix (e.g.,
`C:\Temp\file.txt`). By only storing non-prefixed paths, this also
avoids an error reported by the GUI when it would encounter a prefixed
path:
```
Filter for list-folder-contents must be a path prefix with no wildcards Parameter name: filter
```
Add comment in `WindowsSnapshot.ConvertToSnapshotPath()` warning how
replacing some manual path construction code with Path.Combine() alone
can lead to invalid snapshot paths.
Revert the change made to `WindowsSnapshot.ConvertToSnapshotPath()`
by pull request #4256.
The change in #4256 replaced some existing manual path construction
code with a call to `SystemIO.IO_WIN.PathCombine()`, but calling
`SystemIO.IO_WIN.PathCombine()` this way did not always result in
valid VSS paths. For example, trying to back up a root volume like
"C:\" would result in the following error:
```
The filename, directory name, or volume label syntax is incorrect.
```
This allows us to simplify the ProblematicPathTests because the test
teardown methods can now handle deleting directories containing
problematic paths.
Kenneth Hsu