Gui restore works, commandline doesn't

This is a very small backup set (about 120 MB). Here is the commandline and the results:

mono /usr/lib/duplicati/Duplicati.CommandLine.exe restore file:///media/nc-data/e/db C:\ProgramData\Duplicati\data\YHNDBKYESM.sqlite --passphrase=xx --restore-path=/media/nc-data/e/db
Restore started at 2/6/2021 11:21:44 PM
Listing remote folder …
Downloading file (1021 bytes) …
Downloading file (45.01 KB) …
Downloading file (65.18 KB) …
Checking remote backup …
Listing remote folder …
Checking existing target files …
Scanning local files for needed data …
Verifying restored files …
Restore completed without errors but no files were restored
Restored 0 (0 bytes) files to /media/nc-data/e/db
Duration of restore: 00:00:00

and yes I’m trying to restore and unrelated DB

I’ve tried various iterations of this, plus trying the find command. No errors are thrown in any of these cases, but no files or lists are returned either. (A ‘list’ command shows just one fileset numbered 0).
There is no dbpath - my understanding is that for restores, all you need is the URL (local in this case) and the files (including wildcards) you want to restore.

I feel like this should be an easy solution - but I’ve been staring at it for so long, I’m sure I just need another set of eyes looking at it.
Thanks
Rick

and I answered part of my own question. Those pesky quotes around the file name!

correct command should be:

mono /usr/lib/duplicati/Duplicati.CommandLine.exe restore file:///media/nc-data/e/db “*.sqlite” --passphrase=xx --restore-path=/media/nc-data/e/db

This yielded another question: If I use find with this command, it finds a single file (it is a backup with 1 file in it for testing):

C:\ProgramData\Duplicati\data\YHNDBKYESM.sqlite (109.93 MB)

Now coming from windows, that looks like a file that is 3 directories deep, but it is NOT!

Looking at the gui, it appears as if “C:\ProgramData\Duplicati\data” is a single directory, with the sqlite file underneath that.

I don’t know if I’m getting too far into the weeds here, but how would I find (or restore) a fully qualified pathname like this (C:\ProgramData\Duplicati\data\YHNDBKYESM.sqlite) ?

I’ll leave two command examples with a giant “HUH?”

Given the pathname above from windows

this one works
mono /usr/lib/duplicati/Duplicati.CommandLine.exe find file:///media/nc-data/e/db “C:\ProgramData\Duplicati\*\YHNDBKYESM.sqlite” --passphrase=r

and this one does not
mono /usr/lib/duplicati/Duplicati.CommandLine.exe find file:///media/nc-data/e/db “C:\ProgramData\Duplicati\data\YHNDBKYESM.sqlite” --passphrase=r

Obviously, the program is parsing the 2 lines differently. In most of my experience, they should result in the same string being passed to the find command.

Some of this looks like bugs. Cross-OS (backup on Windows, restore on Linux) might not be done much.
I’ve led people through the GUI. Trick is to use Pick location, because Original location doesn’t fit.
Your restore-path seems the CLI equivalent. Restoring a DB to backup folder is unusual but might be OK.

Got a link? This surprised me, but seems to sort of work. It might be recreating a local database for you in

sort of like the GUI Direct restore from backup files, so that might either get work each time, or a stale DB.

My usual advice for trying to match a GUI job in true CLI is to edit from an Export As Command-line which will use the same DB and options (and help to avoid some quoting problems, or omitted relevant options).

This gets deeper than I can go. I don’t know if any current developers know the area well, but you can try.
How about filing an issue with full steps? This one seems easy compared to the Nextcloud strangeness.

My guess at giant “HUH”? is below. I guess adding ‘*’ anywhere (even end works) switches to Wildcard.

which then switches code below

where a profiling log in the wildcard case does the expected replacement of my what’s-the-point * to %.

2021-02-08 21:07:16 -05 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: Starting - ExecuteNonQuery: INSERT INTO “Filenames-8CEC364060063A4B87C668B2A9BA88FE” SELECT DISTINCT “Path” FROM “File” WHERE “Path” LIKE “C:\Program Files\AESCrypt\aescrypt.exe%”

Without the *, I get a substitution that I can’t track down, but weirdness at start may explain the non-find.

2021-02-08 21:04:15 -05 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: Starting - ExecuteNonQuery: INSERT INTO “Filenames-2CC2F50D7E4D654AAFDE2B387080CD44” SELECT DISTINCT “Path” FROM “File” WHERE “Path” LIKE “%/C:\Program Files\AESCrypt\aescrypt.exe”

5. The LIKE, GLOB, REGEXP, and MATCH operators

A percent symbol ("%") in the LIKE pattern matches any sequence of zero or more characters in the string.

which is what a ‘*’ often means (thus the replacement with ‘%’), but why is it added, and what’s with ‘/’?

Windows running a find without the cross-platform complication didn’t even pattern-match. I think it did

2021-02-08 22:11:06 -05 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: Starting - ExecuteNonQuery: INSERT INTO “Filenames-8C5EFEF21748C747A1F886925DB155E8” SELECT DISTINCT “Path” FROM “File” WHERE “Path” = “C:\Program Files\AESCrypt”

but I think a developer on Linux with at least the right tools and ideally right knowledge should investigate.
Can you write a good step-by-step that such a developer can do, and get it in the line as a GitHub issue?

I completely agree that trying to force the square-peg-of-windows command parsing into the round-hole-of-linux may be a fool’s errand and I’m sure that in some bash manual I’ve long ago forgotten about, these differences were explained. But I’ll see what I can piece together and submit to github issues.

This whole exercise has been trying to do a full verify from my local server, rather than over the network. I have it mostly figured out.

When the ‘test’ command goes and grabs a random database: I think I’ve tracked that back to when I first started using duplicati and was NOT using the server install. When I transitioned over to server with the help of some excellent articles (Migrating from User to Service install on Windows)

the database moved from c:\users\xyz\appdata\local\duplicati\ to \programdata\duplicati\data

However, what got left behind was the duplicati-server.sqlite in the old appdata location. For some reason the ‘test’ CLI command accesses that old location for a dbpath (maybe the default built-in to the code?), hence the error. Running ‘test’ from the GUI does not make the same mistake.

Thanks again

Rick

How did this divert to the ‘test’ command? There were many pieces above, but I don’t see that one there.

From CLI, the ‘test’ command (and probably any command) allocates a per-destination database for you.
The database for a given destination URL is noted in the dbconfig.json file, which can be edited if needed.

The true CLI (as opposed to GUI Commandline) is independent from the server, and should match server options, e.g. by using Export As Command-line as described earlier, unless CLI goal is to be independent.

The CLI DB path, while set and remembered for convenience, can be overridden using –dbpath if you like.

So is there a comment on the find command and other issues? This is more than just a DB-finding thing.

Apologies – I’ve been using the ‘test’ command lately, and my brain said ‘find’ and my fingers typed ‘test’

I really need more sleep……

Looking over my response – no wonder you were confused!!

But in your answer, you gave me some more clues the next time I descend into the rabbit hole, specifically about the dbconfig.json file.

Thanks
Rick