The issue template requests steps to reproduce it, because it helps developers a lot if they can do that.
This means that ideally a problem is reproducible from scratch on a system with a simple storage type.
Generally my steps for generic issues start with a new backup to local files because that always exists.
You should probably keep things simple and private enough that you don’t need to redact or explain lots.
If you can’t reproduce the issue, and it relies on your exact backup, the DB bug report might give a clue.
But it would give a clue here too, if you would do it. Also still waiting to hear how the affected turns out.
If it says there’s an issue and list-broken-files says there isn’t, then someone can try investigating.
Much of this area hasn’t changed in a long time, but developers have, so do what you can to help them.
There may be some interactive Q&A. I’m just giving generic thoughts on what makes a good bug report.
If you want to get very technical you can try to see if list-broken-files actually looked at remote directory, using whatever methods are available. I don’t know if Nextcloud can see it. Duplicati live log can show it.
Unfortunately list isn’t logged in DB. I see after-backup list in DB, but not from list-broken-files.
This is using the Test button. Live log says:
Jan 31, 2021 8:49 AM: Backend event: List - Completed: (7 bytes)
but I can’t click on it to show what it saw. If I go to <job> → Show log → Remote I get expandable below
Jan 31, 2021 8:49 AM: list
list-broken-files does this in live log (Information level is enough):
Jan 31, 2021 8:54 AM: Backend event: List - Completed: (7 bytes)
but job Remote log doesn’t have anything, nor does the DB if I look inside. There my last Operation was
ID Description Timestamp
11 ListBrokenFiles 1612101273
but last RemoteOperation was earlier
ID OperationID Timestamp Operation Path Data
17 10 1612100948 list
Previously, I even ran Sysinternals Process Monitor to see if it looked, and it looked like it did, but not log.
But this level of looking is not typical. If you can come up with a reproducible test, that should be great…
Above diversion was partly to see if I could have you see what list-broken-files saw. Answer is not easily.
Here’s a run of an affected where I hid a dblock file by giving it a prefix of hidden- (easy to undo later):
Running commandline entry
Finished!
The following filesets are affected:
0 : 1/30/2021 6:06:40 PM
1 : 1/30/2021 8:02:45 AM
A total of 2 file(s) are affected:
C:\backup source\A.txt
C:\backup source\short.txt
The following related log messages were found:
1/30/2021 1:02:45 PM: {"Size":1135,"Hash":"M6MBDkzuoW1M8kAVef6I92X5ImsLOuRfSBMRiJlVbfc="}
1/30/2021 1:02:46 PM: {"DeletedFiles":0,"DeletedFolders":0,"ModifiedFiles":0,"ExaminedFiles":2,"OpenedFiles":2,"AddedF ...
1/30/2021 1:03:55 PM: {"MainOperation":"Test","VerificationsActualLength":3,"Verifications":[{"Key":"duplicati-2021013 ...
1/30/2021 1:03:56 PM: {"Size":1135,"Hash":"M6MBDkzuoW1M8kAVef6I92X5ImsLOuRfSBMRiJlVbfc="}
Return code: 0
Below is a list-broken-files view. It’s on 2.0.5.112, but there are no changes documented in the area.
Running commandline entry
Finished!
Listing remote folder ...
1 : 1/30/2021 8:02:45 AM (2 match(es))
C:\backup source\A.txt (1 bytes)
C:\backup source\short.txt (19 bytes)
0 : 1/30/2021 6:06:40 PM (2 match(es))
C:\backup source\A.txt (1 bytes)
C:\backup source\short.txt (19 bytes)
Return code: 0
I think it should be as good at seeing problem files on the server. Of course it can’t see download issues.
The main advantage is that it’s probably faster, and it won’t tie things up as much on the Duplicati clients.
A disadvantage is that if it runs while Suplicati is doing things, it might view client’s file changes as errors.
Issues is where to file. I covered what to include to try to get an answer. Very vague bugs aren’t workable. There are a lot of old ones sitting there not moving, and a reason is that one can’t make anything of them.
rick55: