Does the AFFECTED command need a local DB?

Support
1

When I run the affected command using Duplicati.CommandLine.exe and supply only storage URL and remote filename, this message is returned:

No files are affected
Found 0 related log messages (use --full-result to see the data)

When I supply the database location using advanced option --dbpath, Duplicati returns results as expected: some backup versions and a few file names.

2 questions about this:

  • Is a local database required to execute the affected command?
    If yes, this is not includes in the help text ( Usage: affected <storage-URL> <remote-filename> [<remote-filenames>] [<options>]). are optional, no explicit mention of --dbpath.
    If no, why doesn’t the command give the expected results without supplying the --dbpath option?
  • If a local DB is required, the output is misleading. The message could be interpreted as “this file is not needed, it can be deleted safely”. Message should be something like Local database not found. Please specify the location with advanced option --dbpath.

Note: --full-result doesn’t show any additional information. Shouldn’t this be --verbose?

2

Yes. The “affected” command uses the database to look up which paths rely on a particular remote file.

I agree!

Logging is always a mess: you get too much, then too little :slight_smile:

The --verbose outputs lots of junk that you may not want. --full-result simply expands the results (normally truncated to 10 entries) but does not show all the other information. Setting --verbose implicitly activates --full-result.

2 Likes
3

I have fixed it in source now.

1 Like
4

Cool! Never noticed this one in the long list of advanced options. In some scripts I use, I had to remove sensitive information like passphrase and credentials from the generated output. Thanks for the hint.

5

Agreed whole heartedly! --full-result works WAY better than --verbose for my compare needs! :+1:

6

Usage: affected <storage-URL> <remote-filename> [<remote-filenames>] [<options>]

If the affected command only works with access to a valid local database, why is a storage URL required?
The find command uses the storage-URL if no local database is specified to download information directly from the backend.
If affected does not work without a local DB specified, supplying <storage-URL> is redundant, because it will never be used for anything.

  • Is this a correct assumption?
  • Could the affected command retrieve the results in a reasonable amount of time without access to the local database, analyzing the remote files directly like the find command does?
7

Yes. There is an “automatic pairing” system for the local database. It can be found in ~/.config/Duplicati.dbconfig.json. The file maps the remote destination (scheme, server, path, port, username) to a database path.

The idea is that the user does not need to type in the --dbpath option, but the correct database is found anyway. I am unsure of well it works in practice. I think some users find it to be a bit too “magical” to rely on it, which is made worse because the UI does not rely on it.

So yes: the storage-url is redundant, if the local database path is supplied. But unless we decide to drop the “magic” pairing, I think we should maintain the format.

Not really. Without the local database, it would need to download all dlist files, then probably all dindex files to figure out which dblock files belong where. This is essentially the same as rebuilding the local database.

1 Like