In revision c41f2c6a60 ("moved all sanitization logic into backup class
and moved from regex to using internal Uri library"), we cleaned up the
removal of passwords from an exported backup configuration. However,
the use of Uri.QueryParameters resulted in exporting decoded parameter
values, which violated some assumptions made by the decode_uri function
in AppUtils.js. This caused usernames in the JSON to contain '@'
instead of '%40', which led to incorrect decomposition of the target URL
into its components in the UI.
This concerns issue #3619.
Checks whether it has been set and acts accordingly to avoid exceptions
Update migration to initialize all existent rows to Description=''.
Note that after some research, default values for TEXT columns were not
supported by MySQL a few years ago, however Duplicati uses SQLite
which seems to fully support this feature. If not, a workaround is to use:
ALTER TABLE "Backup" ADD COLUMN "Description" TEXT NULL;
UPDATE "Backup" SET "Description"='' WHERE "Description" IS NULL;
ALTER TABLE "Backup" ALTER COLUMN "Description" TEXT NOT NULL;
The previous implementation returned false for null or empty or
whitespace values, and true for unparsable values. A default value of
false seems more appropriate for these cases.
The previous implementation returned true for null, empty or whitespace,
or unparsable values. A default value of false seems more appropriate
for this setting.
Since the ServerSettings constructor initializes the m_values Dictionary
with keys from the CONST class, we can assume that the
SERVER_PORT_CHANGED key exists.
The previous implementation returned true for null, empty or whitespace,
or unparsable values. A default value of false seems more appropriate
for these settings. In particular, if no warning or error has occurred
yet (e.g., upon first installation), these properties should return
false.
This addresses issue #3126.
The previous implementation:
1. Assumes that the relevant key exists in the Dictionary.
2. Returns true if the value is null, empty or whitespace, or
unparsable. Otherwise, it returns the parsed value.
This simplifies the code while capturing the same logic.
The previous implementation:
1. Assumes that the relevant key exists in the Dictionary.
2. Returns true if the value is null, empty or whitespace, or
unparsable. Otherwise, it returns the parsed value.
This simplifies the code while capturing the same logic.
InvariantCulture is useful when comparing / sorting human language strings in a culturely correct way. It handles things like accented letters in a way that makes sense to humans (e.g., 'a' should be sorted next to 'á', rather than after 'z').
Ordinal looks just at the raw code points of the characters. As such, it is recommended for use in cases when comparing system strings (file paths, command line parameters, config settings, etc.). Since it doesn't need to use the culture specific sorting rules, this method can often be faster.
For more information, see https://stackoverflow.com/questions/492799/difference-between-invariantculture-and-ordinal-string-comparison (and other related questions)
Kenneth Skovhede