2.1.0.122 Canary ngclient stop uploads a short dlist file

[ts678]

@kenkendk

@ts678

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.

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

I originally found this on my production backup, where some source files change.
This is a little hard to describe a repro for, so I tried a simple one with no change.

I have a big tree of empty files with multiple folder levels, so I can pick start point.

• Did a run, got a dlist
• Did a run, with elevated-auto-VSS on. Interrupted while counting. Got a dlist.
• default snapshot-policy=Off, did a run, interrupted while counting. Got a dlist.
• Did a run, got a dlist.

In FilesetEntry, all FileID follow the same pattern of 1 to N. Interrupted N end earlier.

In old ngax UI:

In new ngclient UI:

EDIT 1:

Fifth run did not make a fifth dlist, as I don’t have upload-unchanged-backups on.

I did get several warnings which are hard to spot in ngclient, but spring up in ngax.
Two “Cancellation was requested by user.” seem to match my Stops, so seem OK.

In jobs logs, four list got warning like this, but I’m not sure what I did at the time:

2025-07-07 16:44:45 -04 - [Warning-Duplicati.Library.Main.Backend.BackendManager-BackendManagerShutdown]: Backend manager queue runner did not stop

EDIT 2:

Using ngax and clicking Restore at 5:36:30 gets this series. Different issue I suppose:

[kenkendk]

@ts678

this worries me because new Restore doesn’t note that it’s a partial file.

If I understand correctly, the issue is that ngclient does not show if a backup is partial or not?

If so, I have created an issue for it.

[ts678]

@kenkendk

If I understand correctly, the issue is that ngclient does not show if a backup is partial or not?

I’m also asking what should happen in the different ways that ngclient and ngax can “stop”.

You talked about this lightly in another topic. If short dlist is correct for ngclient, then it’s just the issue you filed. If it’s not, then there’s more. I didn’t try a test where a dindex and dblock file had already uploaded before I did the stop. Maybe it would do the short dlist after those.

EDIT 1:

Release: 2.1.0.120 (Canary) 2025-06-24 is the other topic, so I replied to points there there.

[kenkendk]

@ts678

I’m also asking what should happen in the different ways that ngclient and ngax can “stop”.

I don’t fully understand this part. Both ngclient and ngax call the same endpoint, and from there the code performs exactly the same. Are you seeing a difference between stop from ngax and ngclient?

“Stop after current file” in ngax corresponds to “Stop” in ngclient.
“Terminate” in ngax corresponds to the skull-icon “Stop” in ngclient.
Is this the part that is creating the difference?

[ts678]

In 2.1.0.124 at least, ngclient has only one stop button. It flashes skull icon by itself.

ngclient stop button + skull flash:

api/v1/task/32/stop

api/v1/notifications
[Warning-Duplicati.Library.Main.Operation.BackupHandler-CancellationRequested]: Cancellation was requested by user.

ngax stop button + Terminate:

api/v1/task/34/abort

api/v1/notifications
"Message": "A task was canceled."

Release: 2.1.0.120 (Canary) 2025-06-24 has some screenshots and replies to replies.
Since this topic is dedicated to the issue, it’s probably good to do the followups here…

EDIT 1:

On an ngclient backup that takes longer, the Stop button sends “stop” as before, but the skull icon hangs around long enough for me to click it, at which point it sends an “abort”.

EDIT 2:

I was wondering whether “abort” would message as ngax does, but in the end it got the

[Warning-Duplicati.Library.Main.Operation.BackupHandler-CancellationRequested]: Cancellation was requested by user."

[kenkendk]

@ts678

ngax stop button + Terminate:

api/v1/task/34/abort

api/v1/notifications
"Message": "A task was canceled."

Yes, that is the difference between ngclient and ngax.

With ngax, you are asked to decided if you want to do “soft stop” or “hard stop” essentially.

With ngclient, we decided to nudge you to do “soft stop” and then, if that is not working fast enough, you can issue the “hard stop” afterwards.

I think this explains the differences between the two?

[ts678]

@kenkendk

With ngclient, we decided to nudge you to do “soft stop” and then, if that is not working fast enough, you can issue the “hard stop” afterwards.

Except it doesn’t work that way (or at least not always). “It flashes skull icon by itself.” isn’t saying it puts up the button in case you get tired of waiting. It goes up and down by itself…

EDIT 1:

and my EDIT 1 to earlier post said how a longer backup worked, and it’s like you just said, and in my EDIT 2 to earlier post, maybe a “Cancellation was requested by user.” is meant when ngclient first clicks Stop button, even if skull icon comes up and abort is later asked?

There’s a note around here somewhere that ngax no longer does that, but speaks of tasks.

[kenkendk]

@ts678

Except it doesn’t work that way (or at least not always). “It flashes skull icon by itself.” isn’t saying it puts up the button in case you get tired of waiting. It goes up and down by itself…

The way it works is you only get the “soft stop” button shown. After you issue a “soft stop” (with a click), the button changes to the skull button to indicate that if you click again, it will use “hard stop”.

The logic is that if you click the stop button and wait a little, it usually completes, but if you don’t want that you can click the button again. I think you are saying this is how it works, but not sure if the logic is confusing or you see something else?

@ts678

maybe a “Cancellation was requested by user.” is meant when ngclient first clicks Stop button, even if skull icon comes up and abort is later asked?

If I understand correctly, then yes, the initial click is “User requested cancellation”. This will show the skull icon, but not terminate it. If you click again, it will call the abort endpoint that will cancel the process where ever it may currently be.

[ts678]

@kenkendk

or you see something else?

I was seeing something else as described in the text you quoted. It requires no second click, although possibly it’s timing-dependent, for example maybe skull auto-clears upon complete. Forcing user to clear it when soft-stop has already run to completion would seem a worse UI.

Test .122 again on a backup that takes more than an instant to run supports auto-clear idea. Watched the skull sit there awhile, didn’t click it, backup completed, and skull icon vanished.

[kenkendk]

@ts678

Forcing user to clear it when soft-stop has already run to completion would seem a worse UI.

I agree.

@ts678

Test .122 again on a backup that takes more than an instant to run supports auto-clear idea. Watched the skull sit there awhile, didn’t click it, backup completed, and skull icon vanished.

Yes, that is the idea. The button “changes” to a terminate button after being clicked once. When the backup (or current task) completes, the button goes away.