Support to use an empty password if really desired
Subcommands `init` and `key add|passwd` now support the flag
`--allow-empty-password` which disables the check for an empty password.
`restic` warns about it, though.
Support for `RESTIC_PASSWORD_FILE` and coresponding CLI option has been
added as well. You may user either an empty file or just `/dev/null`.
Basic support for Bash completion is there. But I am unsure if I got the
semantic right. Haven't done something like this before. It lacks
support for other shells.
Internal the empty password is represented by an arbitrary, non-valid
UTF-8 byte sequence (`0xff`) to allow to distinguish between not yet
loaded and empty password.
See https://stackoverflow.com/a/30741287.
This is just a PoC, I haven't ever written a single Go line before.
Subcommands `init` and `key add|passwd` now support the flag
`--insecure-password` which disables the check for an empty password.
`restic` warns about it, though.
Support for `RESTIC_PASSWORD_FILE` and coresponding CLI option has been
added as well. You may user either an empty file or just `/dev/null`.
Basic support for Bash completion is there. But I am unsure if I got the
semantic right. Haven't done something like this before. It lacks
support for other shells.
Internal the empty password is represented by an arbitrary, non-valid
UTF-8 byte sequence (`0xff`) to allow to distinguish between not yet
loaded and empty password.
See https://stackoverflow.com/a/30741287.
This is just a PoC, I haven't ever written a single Go line before.
Conceptually the backend configuration should be validated when creating
or opening the backend, but not when filling in information from
environment variables into the configuration.
This unified construction removes most backend-specific code from
global.go. The backend registry will also enable integration tests to
use custom backends if necessary.
In order to change the backend initialization in `global.go` to be able
to generically call cfg.ApplyEnvironment() for supported backends, the
`interface{}` returned by `ParseConfig` must contain a pointer to the
configuration.
An alternative would be to use reflection to convert the type from
`interface{}(Config)` to `interface{}(*Config)` (from value to pointer
type). However, this would just complicate the type mess further.
As the `Fatal` error type only includes a string, it becomes impossible
to inspect the contained error. This is for a example a problem for the
fuse implementation, which must be able to detect context.Canceled
errors.
Co-authored-by: greatroar <61184462+greatroar@users.noreply.github.com>
The SemaphoreBackend now uniformly enforces the limit of concurrent
backend operations. In addition, it unifies the parameter validation.
The List() methods no longer uses a semaphore. Restic already never runs
multiple list operations in parallel.
By managing the semaphore in a wrapper backend, the sections that hold a
semaphore token grow slightly. However, the main bottleneck is IO, so
this shouldn't make much of a difference.
The key insight that enables the SemaphoreBackend is that all of the
complex semaphore handling in `openReader()` still happens within the
original call to `Load()`. Thus, getting and releasing the semaphore
tokens can be refactored to happen directly in `Load()`. This eliminates
the need for wrapping the reader in `openReader()` to release the token.
The output is now
```
-v, --verbose be verbose (specify multiple times or a level using --verbose=n, max level/times is 2)
```
instead of
```
-v, --verbose n be verbose (specify multiple times or a level using --verbose=n, max level/times is 2)
```
doak
Michael Eischer
Alexander Neumann
Andrea Gelmini
arjunajesh
greatroar