Before performing test write, reset stream Position to 0, otherwise test performs zero-byte write.
When performing test read, verify that file was written correctly.
.NET 5 moves the responsibility to the operating system, and since
SSH.NET currently relies on the ECDsaCng class, we will simply interpret
all exceptions to mean lack of ECDSA support.
It's possible that our test will no longer be valid (e.g., due to
changes in SSH.NET), so we don't want the backend to fail if our test
is no longer valid.
In pull request #4443, we renamed some of the Azure and S3 options to
use dashes '-' instead of underscores '_' for consistency. However, our
treatment of the options in the backend constructors still required that
the underscore versions be present even if the dashed version was
provided.
Now, we allow for either option to be present, but the value for the
dashed version will take precedence.
Allow users to authenticate using a Shared access signature (SAS) token. SAS tokens are more secure because they:
* have a start and expiry date/time
* can be restricted to specified IP addresses
* can limit access scope to a single Storage blob container
The lines with null-coalescing operator (??) throw an exception when the dictionary does not contain the first key (eg azure_account_name). Exception thrown: "The given key was not present in the dictionary".
SSH.NET relies on the System.Security.Cryptography.ECDsaCng class for
ECDSA algorithms, which is not implemented in Mono (as of 6.12.0.144).
This prevents clients from connecting if one of the ECDSA algorithms is
chosen as the host key algorithm. In the event that this causes a
connection failure, we will prevent the client from advertising support
for ECDSA algorithms and make another connection attempt.
Related forum discussion:
https://forum.duplicati.com/t/release-2-0-6-1-beta-2021-sftp-failure-synology/12358
This seems to have been previously included when the job ran on Ubuntu
18.04.5. Now that it has been upgraded to Ubuntu 20.04.2, the gtk-sharp
libraries appear to be missing.
The implementations of ISystemIO.FileOpenWrite call File.OpenWrite,
which does not truncate the existing file. As such, if we overwrite a
larger file with a smaller one, tail remnants of the existing file will
remain.
Since most of the put operations involve unique filenames, this is only
a problem when overwriting existing files (e.g.,
duplicati-verification.json).
This fixes a regression introduced in revision 71c6aca8a7 ("Fixed IO
calls in Filebackend") from pull request #3456. The previous
implementation called File.Open with FileMode.Create, which truncates
existing files.
This fixes#4486.
