GUI running of test command line fails

In the GUI running on Linux, under Advanced I click commandline. On the next page, I select “test” as the command, leave everything else as-is and then click ‘Run “test” Command Now’.

I get the following error message:

Running commandline entry
Finished!

System.FormatException: Input string was not in a correct format.
at System.Number.StringToNumber (System.String str, System.Globalization.NumberStyles options, System.Number+NumberBuffer& number, System.Globalization.NumberFormatInfo info, System.Boolean parseDecimal) [0x00057] in :0
at System.Number.ParseInt64 (System.String value, System.Globalization.NumberStyles options, System.Globalization.NumberFormatInfo numfmt) [0x00014] in :0
at System.Int64.Parse (System.String s, System.IFormatProvider provider) [0x00008] in :0
at System.Convert.ToInt64 (System.String value) [0x0000c] in :0
at Duplicati.CommandLine.Commands.Test (System.IO.TextWriter outwriter, System.Action1[T] setup, System.Collections.Generic.List1[T] args, System.Collections.Generic.Dictionary2[TKey,TValue] options, Duplicati.Library.Utility.IFilter filter) [0x0007f] in <71ed3aa6fd0e4ec4934b502e9e6ebc99>:0 at (wrapper delegate-invoke) System.Func6[System.IO.TextWriter,System.Action`1[Duplicati.Library.Main.Controller],System.Collections.Generic.List`1[System.String],System.Collections.Generic.Dictionary`2[System.String,System.String],Duplicati.Library.Utility.IFilter,System.Int32].invoke_TResult_T1_T2_T3_T4_T5(System.IO.TextWriter,System.Action`1<Duplicati.Library.Main.Controller>,System.Collections.Generic.List`1,System.Collections.Generic.Dictionary`2<string, string>,Duplicati.Library.Utility.IFilter)
at Duplicati.CommandLine.Program.RunCommandLine (System.IO.TextWriter outwriter, System.IO.TextWriter errwriter, System.Action`1[T] setup, System.String args) [0x003fb] in <71ed3aa6fd0e4ec4934b502e9e6ebc99>:0
Return code: 100

FWIW, when I try manually running in a terminal, it asks for my encryption passphrase and then just sits there eating CPU indefinitely. The command I’m entering is:

duplicati-cli test “ssh://192.168.1.77:770//duplicati_data?auth-username=someone&auth-password=something&ssh-fingerprint=ssh-rsa%202048%205C%3A8E%3A33%3A8E%3A1C%3A3D%3AC1%3A5C%3A87%3AF1%3AF8%3A9B%3A44%3AC1%3A96%3A01”

I’ve also tried the above changing the // before the directory name to a single /, with the same results.

I’d appreciate help with either way of running the test. My goal, once I have a basic test command working, is to run it with the --full-remote-verification option, since I’ve had some problems with hash error messages showing up.

Thanks!

Does this topic help at all?

OK, the trick was to not only clear out advanced options, but to also clear out in the GUI Commandline arguments, which has the path for my sftp directory. (How it knows where to check without that parameter is a mystery to me.)

EDIT: I take it back. I don’t get an error but it isn’t accessing any data either.

EDIT 2: click stop didn’t do anything, and clicking X by the status bar brought up a dialog, and clicking stop now didn’t do anything either. I had to kill the duplicati processes to abort the failed test.

OK. Finally have it working. Leaving everything as is but clearing the path to my backups from commandline arguments gets it to work for a small sample.

However, trying to add all gets an unrecognized argument error and is ignored.

So we’re getting close. How do I get test to fully examine my entire backup, not just a sample?

Thanks for working through that - the “How to test” link above should cover what you are asking, but to summarize, replace all “Commandline arguments” with these (each on their own line):

  1. all (to test ALL of your destination files)

  2. --full-remote-verification=true (to download, decrypt, compare to database, then test extract & hash check random 30% of contents from each dblock file - otherwise it just does a hash check of the archive file itself, not the individual content files). Note that you’ll need to make sure --passphrase is in your “Advanced options” if you are using --full-remote-verification and your backups are encrypted

We seem to be doing well now. There was no complaint about all when placed in the commandline GUI box (along with --full-remote-verification=true), unlike when placed in advanced options.

There was no need to provide the encryption password since it was already filled in in the GUI. (Which makes me wonder where it is stored, but that’s another discussion.)