Release: 2.1.0.119 (Canary) 2025-05-29

[webipsum]

@ts678
Add advanced option on settings page: with scroll.
Add advanced option on backup page: without scroll.
Chrome, Firefox and Safari.

[ts678]

Thanks for clarifying. So that’s different from my result, and maybe is macOS specific.
We can see if anyone with macOS can reproduce the results and get an issue written.

[webipsum]

@ts678

To clear up my doubts, I installed it on Windows and:

1. In Duplicati Settings, all Advanced Options are available in the drop-down list. Just like in macOS. The complete list appears.
2. In Backup Settings, only the same (few) options that appear in macOS are available. Windows 10 items appear. macOS 7 items appear.

Very strange.

EDIT: Backup destination

Google Chrome and Firefox.

[ts678]

Please identify your screenshots. It looks like you’re on the Destination screen.

Firefox Destination screen here for File destination type only has ones for File:

Different types of destinations have their own specific short advanced options.
--use-move-for-put is only for File. If you look at, say, S3, the list gets huge.

You should be using the Options screen (the last one) for the option you want.

--suppress-warnings option is not a Destination option. Go to Options page.

One thing I see that might be good, or bad, or a compatibility problem is that the old UI sometimes could show the Destination options on the Options screen as well, like this:

The new UI Options screen only shows what I’d call more generic destination options:

EDIT 1:

and if you think it’s just me not noticing the B2 ones, Search isn’t finding them either.
A compatibility worry is we told people to use Options screen for Destination options.
This is because Destination options were removed on next Edit, due to a bug in Edit.

[webipsum]

@ts678

--suppress-warnings option is not a Destination option. Go to Options page.

Thank you for your explanation.
Now I understand.
I used the option page.

[Wim_Jansen]

@kenkendk

To remedy existing data, the test method can now be run and only check index files (--full-remote-verification=indexesonly).
By default, any defective index files that are found will be replaced with correct versions, so simply running the test command with a large sample size will fix the backup.

Running a backup with following options:

--replace-faulty-index-files=true
--full-remote-verification=IndexesOnly
--backup-test-samples=99999999

Keeps giving same error messages:

2025-06-14 19:36:32 +02 - [Error-Duplicati.Library.Main.Operation.TestHandler-Test results]: Verified 221 remote files with 97 problem(s)

New files are being uploaded, but every run I get the same message.

[ts678]

Problem of persistent errors is described above, although yours could use more review.
It seemed to me like the resulting dindex files were technically bad, but effectively good.

By bad, I mean they don’t list all blocks in their dblock, by ignoring wasted space blocks.
By good, I mean they get the recreate done without having to download the dblock files.
This is maybe because waste blocks aren’t used by dlist, so all’s well without close look.

Repair can in some cases cause incorrect index files #6339 is the issue, but there’s not much movement on it yet beyond my speculations. If you dare, you can try DB recreate. Direct restore from backup files is one way. Save of current DB then recreate is another. Watching About → Show log → Live → Verbose will show whether it downloads dblocks.

[ts678]

@kenkendk

The file backend is now excempt (by default) from throttle settings via --throttle-disabled-backends.

  --throttle-disabled-backends (String): Disable throttling for specific
    backends
    Disable the throttling of upload and download speeds for specific backends.
    If there is a throttle set, it will be ignore when running this task, if
    the backend is one of the specified backends. Multiple backends can be
    specified with a comma separator. This option has no effect if there is no
    throttle or if --disable-throttle is set
    * default value: file

I sometimes like to throttle file to get timings I want. Those whose file is actually a
network drive might want to throttle for the same reasons as another network use might.

Option value of empty string expresses what I want (basically, throttle if I say to throttle). Unfortunately it doesn’t work, probably because GetString sets empty string to default.

Workaround is to set something bogus but not empty. For example, using comma works.

EDIT 1:

Help text typo: “ignore” should be “ignored”.

EDIT 2:

What I’m trying to repro (without much success) is the new UI backup progress bar being erratic, and seeming (somehow) to track the size of text above it, which varies as it goes.

Another progress bar comment is that the old ngax UI bar is in a box, and 100% is visible, whereas new one just generally grows (except when it shrinks surprisingly) meaninglessly from a how-much-is-left view. I suppose it’s still useful to see if progress has fully stopped.

[jberry02]

On 2 Windows 10 systems - 1 physical, 1 virtual - the install of .119 “did not work”.

The physical system crashed (BSoD) during the install - install, crash reboot, not running .119. Did a “Install->Repair” followed by a reboot and after that it seems to be OK.

The VM was the same only without the crash - install, reboot, not running .119, “Install->Repair”, reboot, now all OK.

[ts678]

New ngclient UI Options screen doesn’t offer new or show set up Destination screen options.
There used to be a bug in old ngax UI where Destination screen options vanished on next job edit (or something like that), with workaround of adding those options on the Options screen.

Is there a continued intent to support destination options both places? If not, how to migrate?

[kenkendk]

@ts678

ngclient was, I thought, totally untranslated, except yesterday I found a tiny amount -
along with my further-down-screen jobs having their contents vanish, e.g. for French:

Found it. It was caused by a wrong path mapping in release mode.

@ts678

Maybe impact is a sudden warning (which did happen) for an apparently ignored option?

If I add it back, it would instead say Warning: *** is deprecated and has no effect.
Slightly more friendly than just Warning: option *** is not supported, but the effect is the same?

@ts678

The migration information provided right here is another impact that should be publicized

Good point. I will add it to the experimental/beta/stable release changelogs, then at least it is searchable.

@ts678

Missing. Here is a sample from the dindex previously mentioned (I just tested again):

Ok, I read the issue report comments, and it is high on my list to investigate.

@Folgore101

On the Home screen some things are translated.

Thanks! I found the issue and then some. It was both a string interpolation issue and an incorrect path loading issue. It is fixed in the next canary.

@Taomyn

But the logging shows better where it’s stuck:

Thanks! I have created an issue for this

@webipsum

Both without scrool.

For the ngax (previous UI), the option box is scrollable as it uses the browser’s option tag to show the list.

For ngclient (the new UI), there is no scroll bar because you are listing destination options, and in this case the list is too short to warant a scroll bar.

@Wim_Jansen

New files are being uploaded, but every run I get the same message.

At least the part that reports the fixed files as failed is fixed in the next build.

@ts678

Option value of empty string expresses what I want (basically, throttle if I say to throttle). Unfortunately it doesn’t work, probably because GetString sets empty string to default.

The intention was that you can set it with an empty string, but I can see that this does not work and makes the option slightly inconsistent. I have a PR that fixes this.

@ts678

Another progress bar comment is that the old ngax UI bar is in a box, and 100% is visible, whereas new one just generally grows

I have not seen that, but if you can provide some screenshots showing the problem, we should get it fixed.

@jberry02

The VM was the same only without the crash - install, reboot, not running .119, “Install->Repair”, reboot, now all OK.

Thanks for the report!

[ts678]

@kenkendk

@ts678

Another progress bar comment is that the old ngax UI bar is in a box, and 100% is visible, whereas new one just generally grows

I have not seen that, but if you can provide some screenshots showing the problem, we should get it fixed.

This part is easily described. ngax uses a box (with a border) which contains the status text and the progress bar. 100% on the progress bar appears to be when it reaches end of box.

ngclient also uses a box, and the pause and throttle controls are in it. The main point about the progress bar being meaningless is that there’s no “complete” length like ngax provides.

The rest of the quote was

@ts678

(except when it shrinks surprisingly) meaninglessly from a how-much-is-left view. I suppose it’s still useful to see if progress has fully stopped.

Had to fish around for tools, but that is by PortableApps ScreenToGif at 1 fps and cropped. Because I dislike continuously running things, you might need to open image in a new tab.

Strange behaviors are where progress goes backwards when message length shrinks, e.g. when variable-width font comes across a narrow number such as 1, or a number is integer which drops the numbers to right of decimal point. This ia all during one phase, but when it changes to later phase, there can also be a jump backwards. Progress is forwards in ngax, which is what I expect even if I don’t have an exact document on interpreting length of bar.

As a side note, there is a 250 KB/sec upload throttle to create a longer display of progress. Other than that, this is my production backup, and I haven’t found a simple alternative test.

[kenkendk]

@ts678

Had to fish around for tools, but that is by PortableApps ScreenToGif at 1 fps and cropped. Because I dislike continuously running things, you might need to open image in a new tab.

Thanks for the gif, I have created an issue for this.

[jberry02]

I have one backup that keeps giving this error:

Detected 176676 file(s) in FilesetEntry without corresponding FileLookup entry

Database repair doesn’t seem to help - anything else to try?

[jberry02]

On various backups I am getting:

Found 1 faulty index files, use the option --replace-faulty-index-files to repair them

• Should this be set globally or only on the problem backup? Should this be left set, or removed after the indices have been fixed?
• Does this find/fix all the faulty index files, or just the ones involved with the files that get verified?
• Is there a one-off operation to find and fix all of the faulty index files in a backup?