Release: 2.1.0.120 (Canary) 2025-06-24

2.1.0.120_canary_2025-06-24

This release is a canary release intended to be used for testing.

The intention is to tap this release as an experimental release if no significant issues are uncovered.

Major changes in this version

This release is mostly fixing minor issues reported from 2.1.0.119, with only a few changes that could impact backups.
A significant amount of fixes has been completed for ngclient.

The repair flow can now detect and fix cases where a file or folder has been assigned no metadata.
Since the codebase does not support this, the current fix is to assign an empty metadata block if possible, and otherwise use the smallest metadata block.
The Test output no longer reports failures on index files that were fixed during the test process.

The destination picker UI in ngclient has been reworked in multiple ways, providing a more robust experience with the Test button and results being more prominent.

The restore flow and file picker has been updated to fix a number of issues with files and folders that have the same prefix.
Some issues with the picker not having the correct visual representation of the state.

Detailed list of changes:

  • Reduced logging from remote connection
  • Filter sent reports by destination to avoid duplicates
  • Disable WebSocket for Agent
  • Added support for using ssh-agent with the SSH backend
  • Detect bind-permissions denied for the Duplicati webserver
  • Improved secret provider pattern matching and misconfiguration detection
  • Updated MailKit library to latest version
  • Updated Windows script example
  • Updated logic for assigning the OAuth url option
  • Messages in test-command handler are now localizable
  • Added attributes for macOS entitlements
  • Detecting EPERM as “Permission Denied” on Linux/macOS
  • Added null checks and invalid email detection for email report module
  • Fixed 100s timeouts on some backends
  • Reduced logging of messages during websocket authentication
  • Changed secret provider option to be a password-type
  • Changed replace-faulty-index-files option name to dont-replace-faulty-index-files
  • Added correct loading and unloading of modules
  • Added back PROPFIND debug options to WebDAV
  • Added support for X-Forwarded-For prefix
  • Added Mega S4 endpoints
  • Added check and repair to detect empty metadata entries
  • Fixed Ids being returned for filesets instead of version numbers
  • Websocket sends update signal after metadata update
  • Websocket has task-completed event
  • Fixed not adding quadruple ---- on restore from config
  • Removed fixed files from test output
  • Handle transitive virtual folders in ListFolderContents

Ngclient changes:

  • Upgraded to Angular 20
  • Fixed some colors not being selected
  • Added plurals for log view
  • Updated destination url picker
  • Fixed issues with quadruple dashes in commandline
  • Added support for “empty” view for backends with no UI configuration
  • Added support for additional localization
  • Fixed MSGraph not showing site-id as mandatory option
  • Avoid undefined in target url
  • Added support for custom OAuth URLs
  • Updated logic in export page to be consistent with the current state
  • Show the version number of the current server on the About page
  • Added zh-Hans to list of languages
  • Fixed issue with localized content not showing icons
  • Fixed issue with localization not being applied
  • Handling of plurals in localization
  • Improved locale support for date/time/number formats
  • Fixed issue with Azure blob storage UI
  • Added summary to log lines headers
  • Marking fields as required in destination configuration
  • Fixed commandline sending empty arguments
  • Prevent adding quadruple slashes
  • All destinations are now in searchable dropdown
  • Fixed some logic detecting an empty folder on restore
  • Showing size of backup data during restore, if known
  • Added backend config for AliyunOSS
  • Improved logic for buttons on the database management page
  • Fixed the “last backup” timestamp not showing the correct information
  • Fixed an incorrect draft backup creation during restore
  • Fixed loader on “Restore files” being shown even when not loading
  • Restore view keeps track of temporarily recreated versions
  • Restore view supports reload of the page and some navigation
  • Database page does not attempt to delete non-existing file
  • Added a check for restores with a backup that is missing a local database
  • Fixed an issue with custom dropdowns in the destination selector not picking the correct value
  • Added FTP to the list of backends (aFTP was already there)
  • Added lazy-loading of custom dropdown values
  • Fixed incorrect size being shown on the “Delete backup” page
  • After direct import, go to home page
  • Improved support for default backup options, retaining more options
  • Fixed a non-working “back” button in the restore flow
  • Added button to copy target url to clipboard
  • Fixed some warning indicators not being correctly colored
  • Updated restore view to support additional complex path configurations
  • Added missing option to include metadata during restore
  • Fixed not adding wildcards to file paths for restore flow
  • Fixed an issue where task completion would sometimes leave the UI in an incomplete state
  • Fixed url-encoding of options for export configuration
  • Better detection of encrypted configuration in import configuration
  • During export, disable buttons until data is correctly entered
  • Fixed “No encryption” option being lost (visualy) on navigation
  • Made the test status more visible and suggest to test on new backups and direct restore
  • Improved waiting for repair to complete during restore without a local database
  • Updated restore flow to better detect a completed restore
  • Reworked all destination dialogs to better support hostname/bucketname, and path-only destinations
  • Updated file picker to work better with multi-select and cross-os support
  • Fixed importing metadata when importing a backup configuration
  • Fixed a number of cases where icons and help-text would be rendered incorrectly
  • Fixed an issue with settings view being obscured by the top-bar
  • Fixed top-level source files in restore being shown as folders
1 Like

Wow, that’s a lot of fixes :+1:

I will start with one of my Windows servers and see how it goes, it also still has repair issues so I will find out if these get sorted. The installer was fine.

Also, I think you missed one, the next run time - using en_GB:

Damn, I spoke too soon on the date/time formats, all wrong here

That is probably related to a fix where other locales failed to load.
I have created an issue.

Enum case issue in ngclient, which tossed out false from --full-remote-verification. ngax shows it as False, however in general that editor seems to evaluate case-insensitive whereas ngclient editor looks case-sensitive. Total issue appears deeper, as ParseEnum in options validation looks case-insensitive, while later C# read of its value are case-sensitive.

Discovered this by accident after import of an export of a job which used false not False. General case sensitivity policy of enum isn’t clear, but I would think insensitive seems safer.

Removing a layer of ngclient bugs (thanks for that) now exposes some bugs further down…

EDIT 1:

For a test, the export/import is not necessary. One can use ngax three-dot Edit as text, which I think I was doing once looking at a weird unreproducible bug where dropdown was not setting the value it should have. I forget details, but maybe the value lagged the select.

EDIT 2:

After import, I did a Verify as a warm-up for Backup, got this warning, then tracked it down.

Warning: 2025-06-25 14:32:32 -04 - [Warning-Duplicati.Library.Main.Controller-OptionValidationError]: The option --full-remote-verification does not support the value "". Supported values are: True, False, ListAndIndexes, IndexesOnly, IndexOnly

Good news for my initial backups on my Windows server - after the upgrade I ran a manual Test All and it showed me 302 warnings and mentioned fixing things. The subsequent backup showed one warning with a repair being formed. The next back up was clean.

I’m going re-run the Test All to see if it really fixed things - it’s just a local backup as I’m not daring to run this on the S3 backup.

I’ve deployed this version on my other Windows servers and will see how they go. Next will be my Linux machines.

I re-ran the Test All twice and I’m confused because it keeps finding things each time yet nothing is happening with the backup files to have changed anything. I’ve zipped up the results of the two runs from the command-line, so maybe you can explain what is going on?

Administrator PowerShell 7 (x64).zip (224.1 KB)

Any options like full-remote-verification setting, or replace-faulty-index-files?
I think there’s a bug in the replace, but at least for me the symptoms of it aren’t like yours.

What sort of warnings?

Know actual message?

What backup files? Source? Destination? Do you mean all files are old?
Although this likely needs dev interpretation, fixing often changes things.

Looking much better. I’m seeing cases where actions still wind up strangely in buttons or new indicator near the path box. Is that supposed to color based on file? Regardless, the unusual endings so far seem fixable with page refresh – but it shouldn’t need that, right?

Backblaze B2 is giving me timeouts on uploads about half the time. 2.1.0.119 wasn’t, but possibly something just got worse in B2, network, etc. This is an old issue we discussed, and for awhile I had a long read-write-timeout (maybe 5 minutes). Now I’m testing default, however that change predates 2.1.0.120 so I don’t know why it seems to run worse lately.

I stumbled onto a bug in old ngax UI (for a change) that 2.1.0.5 works with. A new job that hasn’t been run can’t be deleted. An internal server error results. It works in new ngclient.

There’s a subtlety to it. When you go into the Delete screen, status says Starting backup, which is probably its known mis-target, but dev tools shows it doing progress polls awhile:

Before I noticed that, I was just going right through and asking for delete, and it was failing. Waiting a short while, e.g. until status bar goes idle, seems to manage to delete the job OK.

In comparison, a kind of fast delete looks like this:

The delete that failed above got “{“Status”:“failed”,“Reason”:“backup-in-progress”,“ID”:81}”

The screen got

The profiling log got

2025-06-26 13:39:01 -04 - [Profiling-Timer.Begin-Duplicati.Library.Main.Controller-RunListRemote]: Starting - Running ListRemote
2025-06-26 13:39:01 -04 - [Verbose-Duplicati.Library.SQLiteHelper.SQLiteLoader-CustomSQLiteOption]: Setting custom SQLite option 'cache_size=-333824'.
2025-06-26 13:39:03 -04 - [Error-Duplicati.Server.Program-UnobservedTaskException]: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. (The CancellationTokenSource has been disposed.)
System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. (The CancellationTokenSource has been disposed.)
 ---> System.ObjectDisposedException: The CancellationTokenSource has been disposed.
   at Duplicati.Server.Runner.<>c__DisplayClass16_2.<<RunInternal>b__3>d.MoveNext()
   --- End of inner exception stack trace ---
2025-06-26 13:39:08 -04 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteScalarInt64]: Starting - ExecuteScalarInt64: INSERT INTO "Operation" ("Description", "Timestamp") VALUES (@Description, @Timestamp); SELECT last_insert_rowid();
2025-06-26 13:39:08 -04 - [Profiling-Timer.Finished-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteScalarInt64]: ExecuteScalarInt64: INSERT INTO "Operation" ("Description", "Timestamp") VALUES (@Description, @Timestamp); SELECT last_insert_rowid(); took 0:00:00:00.177
2025-06-26 13:39:08 -04 - [Profiling-Timer.Begin-Duplicati.Library.Main.Backend.Handler-RemoteOperationList]: Starting - RemoteOperationList
2025-06-26 13:39:08 -04 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: List - Started:  ()
2025-06-26 13:39:08 -04 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: List - Completed:  (3 bytes)
2025-06-26 13:39:08 -04 - [Profiling-Timer.Finished-Duplicati.Library.Main.Backend.Handler-RemoteOperationList]: RemoteOperationList took 0:00:00:00.000
2025-06-26 13:39:08 -04 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: Starting - ExecuteNonQuery: PRAGMA optimize
2025-06-26 13:39:08 -04 - [Profiling-Timer.Finished-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: ExecuteNonQuery: PRAGMA optimize took 0:00:00:00.000
2025-06-26 13:39:08 -04 - [Profiling-Timer.Finished-Duplicati.Library.Main.Controller-RunListRemote]: Running ListRemote took 0:00:00:07.164
2025-06-26 13:39:08 -04 - [Information-Duplicati.Library.Main.Controller-CompletedOperation]: The operation ListRemote has completed

On the home page, a job display order issue is that create order doesn’t actually work.

My first two jobs were test 1 and test 2, then at some point the new one went between:

It’s now at ID 19, and my theory is that the sorting is alphanumeric rather than numeric.

I’ll use ngclient to delete the job, then import+save it again to see where it is on screen.

So that’s another sign that it originally sorted as 1 10 2 5 and has now gone to 1 2 20 5.

EDIT 1:

Opened issue while waiting for any comments:

I don’t understand what “true” and “false” mean in this option (Old GUI):

dont-replace-faulty-index-files
Default value: “false”

Use this option to replace index files that are missing content during the testing phase. This takes slightly longer, but will prevent very slow database recreates

I would appreciate clarification on this point, especially since I understand the view in the new GUI to be the opposite.

The dev could probably say more, but Boolean values describes some of the general idea.

A boolean option passed will translate to the value true if it is supplied with no assigned value.

implicitly means (and it’s been more directly said elsewhere) that not giving option is false.

This forces code to choose the default behavior without the option, and here it’s to replace.

If you don’t like that, then add don't-replace ... option with a syntax that means true.

was probably a response to

Ensure booleans are false by default #6333

This PR changes --replace-faulty-index-files to --dont-replace-faulty-index-files, and swaps the default value.

The behavior with no option should be the same, but the way to change behavior changed.

To me, the GUI views look the same, but the help text didn’t change when option did.

I’ll repeat my previous gripe about the new UI not actually showing the option’s name.
I do know what name I chose from the selector menu, but how to reverse the display?

The help made more sense for replace-faulty-index-files idea. It should be changed, however writing to match the boolean false-by-default has a risk of using double-negatives.

One attempt: “Use this option to stop replacement of index files that are missing content during the testing phase. Replacement takes slightly longer, but will prevent very slow database recreates.”

As a side note, the replacement dindex is faulty enough to be replaced again and again, however is probably an improvement for recreate. This has been mentioned a few times.

I have a question for dev or other expert about Stop during backup. The old ngax UI gives two options (one renamed since earlier release). The new ngclient UI doesn’t give options.

Behaviors seem to vary. Can expectations be easily summarized? In particular, I’m seeing ngclient upload a short dlist file when I stop backup when status starts Counting, and this worries me because new Restore doesn’t note that it’s a partial file. This seems like a risk.

What used to be “Stop now” in ngax I think once just stopped without a dlist upload.
Given that these are somewhat controlled stops, is dlist supposed to upload, or is a synthetic file list supposed to happen on the next backup, probably allowing fast stop?

I haven’t tested ngax “Stop after current file”, but it would be nice if docs could explain various ways to Stop. There appear to be three between two UIs. Are some the same?

Unfortunately, I don’t understand what you mean, @ts678.

  1. I’m using the old GUI.

  2. I want defective files to always be repaired.

By switching between the old and new GUI, I came to the following conclusion:

I have to set “dont-replace-faulty-index-files” to “true” so that point 2 is fulfilled.

What do you think?

best regards,
Oliver

From a logic and language point of view, I disagree with your conclusion.
From a testing point of view, my Duplicati does a replacement by default.

says (as it says) “don’t replace”

Point 2 wants “replace”, so by saying "don’t-replace, you don’t fulfill point 2 IMO.

Regardless, you can’t get point 2 because repair is buggy, but you can get a try.

I have a broken one set up because I’ve been putting comments on bad repairs:

Repair can in some cases cause incorrect index files #6339

This is from GUI Commandline where I ran a test with all as commandline argument.

  Listing remote folder ...
  Downloading file duplicati-20250628T185120Z.dlist.zip (662 bytes) ...
  Downloading file duplicati-ie50eeae9178240768df62c778de582ff.dindex.zip (623 bytes) ...
  Downloading file duplicati-b7beedb0d901046ecbfd4f2a5e69af23e.dblock.zip (1.10 KiB) ...
Found 1 faulty index files, repairing now
  Uploading file duplicati-iffa5969b8a6944a0be7988f215d5e2df.dindex.zip (623 bytes) ...
  Deleting file duplicati-ie50eeae9178240768df62c778de582ff.dindex.zip  (623 bytes) ...
Examined 2 files and found no errors
Return code: 0

Let’s test your theory (which I think is backwards) and set “dont-replace-faulty-index-files”:

  Listing remote folder ...
  Downloading file duplicati-20250628T185120Z.dlist.zip (662 bytes) ...
  Downloading file duplicati-iffa5969b8a6944a0be7988f215d5e2df.dindex.zip (623 bytes) ...
  Downloading file duplicati-b7beedb0d901046ecbfd4f2a5e69af23e.dblock.zip (1.10 KiB) ...
Found 1 faulty index files, remove the option --dont-replace-faulty-index-files to repair them
Verified 3 remote files with 1 problem(s)
duplicati-iffa5969b8a6944a0be7988f215d5e2df.dindex.zip: 2 errors
	Missing: 335w5QIVRPSDS77mSp43if68S+gUcN9inK1t2wMyClw=
	Missing: h90JSQPN+uqg6ows41QAIdBiEbLFXeNVDrx740zJLVE=

Return code: 3

Does that convince you to reverse your conclusion? Feel free to test this all out yourself.

Okay, if the repair doesn’t work, it doesn’t matter, and we’ll wait for the repair to be repaired.

But, thinking it through further: If I set up a job in the new GUI and the interface of the new GUI is clear to me regarding the repair, then after switching to the old GUI, the value is set to “True.” For me, the statements in the new/old GUI are contradictory.

I’d suggest not looking into the new GUI, especially since you’re not using it.
Additionally, help text is wrong (as mentioned), and option name isn’t shown.
This leaves one entirely reliant on backwards help text to try to understand…

Regarding improved wording, I looked at what some other “dont” options say:

and you can see that the unchanged help still has the wrong direction stated:

The wrong long statements are exactly identical. Let me repost what I showed above:

The difference is old GUI doesn’t show the reversed short help. It shows option name, providing summary of the option. New GUI shows wrong short help, trying to do same.

You are reading reversed help. Don’t do that, or be aware that help here is backwards.

When option got reversed, help should have reversed. It didn’t. It’s backwards.

EDIT 1:

An option has a name and short and long help. The below were added May 27 for original release of this feature in 2.1.0.119, and were not changed on June 13 with option reverse, which was a coding bug IMO. All you can do for 2.1.0.120 is not rely on the reversed help.

EDIT 2:

So if the short help text were fixed, ngax would show dont-replace-faulty-index-files option name, and ngclient would show (for example) short help of “Don’t replace defective index files”, and would solve the confusion seemingly being caused by bad 2.1.0.120 help.

A question I have for the dev is whether there is an intentional move to reduce visibility of option names. I’ve been asking about that since 2.1.0.118, noting they’re no longer shown:

The missing part here is the option name

Option names in English may be similar to the short help text. If Duplicati someday is well translated, short help text will probably be easier for non-English language settings – until questions arise about what options are being used – at that point option names are better.

The other thing that option names allowed was sorting. This is also very absent in ngclient, where current and potential options are rather unpredictably ordered. Is this seen as good?

Trying to do a database “Delete and Recreate”, but it keeps failing with “The requested file does not exist”. On the latest attempt it failed during “Pass 3 of 3, processing blocklist volume 614 of 616”, so right at the end. I believe the prior attempts also failed near the end but I neglected to check for the details.

I had to stop a backup because it was trying to back up some unexpected files (caused by a mount), so after excluding them in the job and restarted, the next backup completed but had these warnings:

* 2025-07-04 11:10:45 +02 - [Warning-Duplicati.Library.Main.Operation.FilelistProcessor-MissingRemoteHash]: Remote file duplicati-b03e12ebe0ef942ccaca0df767683f72f.dblock.zip.aes is listed as Uploaded with size 80740352 but should be 104923565, please verify the sha256 hash "gIccAeeS41WyigonoSv2KN75bE2zxRvOoPevp/gXFaQ="
* 2025-07-04 11:10:45 +02 - [Warning-Duplicati.Library.Main.Operation.FilelistProcessor-MissingRemoteHash]: Remote file duplicati-b57003259fbb94483a2197cc8b9078f11.dblock.zip.aes is listed as Uploaded with size 72351744 but should be 104923565, please verify the sha256 hash "dFse4iLS6Pt6hfKUpNj0OevS+UGafN4Ejn0bwIxhDjQ="
* 2025-07-04 11:10:45 +02 - [Warning-Duplicati.Library.Main.Operation.FilelistProcessor-MissingRemoteHash]: Remote file duplicati-b648757ae800a466d8017ac66ad222fe6.dblock.zip.aes is listed as Uploaded with size 28311552 but should be 104923565, please verify the sha256 hash "v4XLaYMVyL9JfWPW7TvEprx696Olobuh0Nq2AjPpl60="
* 2025-07-04 11:10:45 +02 - [Warning-Duplicati.Library.Main.Operation.FilelistProcessor-MissingRemoteHash]: Remote file duplicati-bff47b9d9f96541a2b6c25d20d9d3c72b.dblock.zip.aes is listed as Uploaded with size 26214400 but should be 104923565, please verify the sha256 hash "yxKq5j+ZPxVYEWlLKowhI8gxRWPYmxgQgTXvxs242uA="

What’s the best thing to do with this? I think I chose the option to stop immediately, which was maybe a mistake, but it was trying to back up a very large directory.

I have noted a bug - or at the least an inconsistent behavior - when doing a database recreate.

B2 backend.

While attempting to get a failed backup working (more on this later) I used rclone to delete the most recent dlist file. The database “Delete and Recreate” then failed saying it couldn’t “get” the deleted file. At first this confused me - why is it trying to get a deleted file, and more importantly, how does it even know the file existed?

Then I remembered that rclone does a “soft” delete!

Did a “rclone cleanup” and now the recreate is proceeding (at least it is going farther).

So it seems to me that the recreate needs to either not find soft-deleted files, or it needs to note that the file has been soft-deleted when trying to “get” it later.

Problem as reported in the .119 thread:

Analysis: Since it can’t recreate the database, the issue is with the files in the b2 bucket. As backups were running without any apparent error prior to this, it seems that the issue is:

  1. an error in the last backup’s fileset
  2. a more severe error with the rest of the files

If the problem was case 2, there really isn’t anything I could do without special guidance.

Assuming case 1, the obvious action is to delete the most recent backup. However, that fails presumably due to the underlying error.

So instead I pursued a more drastic action. First, using rclone I created a copy of the directory containing the backup files (safety first!), and then deleted the most recent dlist file. After this I was able to do a database “Delete and Recreate” that ran to completion, and I am happy to report that so far it has completed 3 nightly backups without any apparent errors (it did report fixing an index file, but I am getting those on other backups as well).

Hopefully this is now permanently resolved.

Replacing fileset duplicati-20240719T060005Z.dlist.zip.aes with duplicati-20240719T060006Z.dlist.zip.aes which has with 1737 fewer file(s) (49,385.750 TiB reduction)

That is impressive - deleting 49,385 TiB from a backup of a 1TB drive!

This is from a purge. It gave the same message for several dlist files.

EDIT:

I think the message may make sense if:

  • it is counting the space for each fileset (instead of just once)
  • the space is GB rather than TB

i.e. it may actually be purging ~490GB

EDIT 2:

Having checked, the amount of data being purged is only ~300GB.

Thanks for reporting it. I have fixed it in 2.1.0.121. The enums and booleans should be parsed case-insensitive everywhere.

Where is the “later C# read” ? All code that reads an enum option from a string should use the helper method ParseEnum to make sure we always parse the same way.

The enum parsing in the backend configuration area has some quirks with case sensitivity currently. Fortunately, ngax has the same quirks, so you need to hand-edit the url to introduce issues.

Is this because the option was snipped by ngclient? Then it should be fixed in 1.2.0.121.

The indicator should light up if the path does not exist. And no, generally one should never need to refresh the page (but it is a nice workaround.).

That sounds super odd. I cannot recall anything that should apply to B2 timeouts at all. The default read-write-timeout is 30s, so much shorter than the 5m you have been using.

My guess is that it hits some kind of error+retry and that keeps the backup busy. You cannot delete a backup that is running, so most likely this is the case.

Yes, that is the case. I have fixed it in source.

Thanks for reporting.

I understand the gripe, but I think the actual option name is for power users, and has little value for the regular person. I think the option to have the ... edit as text would solve it, by showing the actual option names.

I see, since the option is now inversed, the wording should also be inversed.

I will look at recreating the issue.

There is an issue for creating that button in ngclient.

There are two “pause” modes (which is confusing in itself).

The server can be paused. When the server is paused, it will queue up requests to run tasks (backups, restores, etc). Once the server resumes, tasks will be processed in their queue order.

The other pause mode relates to a single task. Here it is possible to pause (or stop) a task.
With ngclient, the stop button appears when a task is running (but no pause button).
The stop command will request that the operation stops “nicely”, meaning that any pending transfers are completed before the task stops.
There is also a more agressive command (named abort internally) that will instead attempt to stop any processing immediately, potentially leaving partial files on the storage.

That sounds like a bug. Do you mind opening an issue or a new topic for this?

The “Stop now” is the same as abort. It has a skull icon in ngclient, and you need to click “stop” before you can see that button.

For the “soft stop” a new filelist will be uploaded, if any new data was encountered, as the backend will otherwise store “dangling” data until the next backup can upload a (synthetic) filelist.

If the backup was stopped prematurely, regardless of the method, the filelist should be marked as partial.

It is not directly intentional, but making the UI more friendly means that there is not a great place for it. I get that the error here means that the wrong text is shown, but hopefully the new check for inverted booleans should catch such an error in the future.

That sounds like a bug somewhere. The logic is that such failed uploads should be marked is “uploading” in the database, and since the backup did not shut down cleanly, the next run should remove these files as they are not fully uploaded. The error message you see indicates that they somehow got the state “uploaded” or “verified” in the database.

Could you make a bugreport database and PM it to me? Then I will try to figure out where the transition happened.

Since the files are damaged, you should delete them. They cannot really be read due to encryption. After removal, you need to run purge-broken-files.

Do you know how rclone markes files as soft-deleted? I am surprised that Duplicati finds them if they are moved or renamed.

That sounds like a counting bug. Do you mind creating an issue or a new topic for tracking this?