Is this just on FTP? There was a bug/fix on a report of FTP leaving connections open, but the fix was actually in BackendManager. Bug might exist but be hard to notice elsewhere.
Regardless, I’m not seeing this on local folder or Backblaze B2 backups done in the GUI.
A different regression new to 2.1.0.112 that has gotten a second report is one I can repro:
Restore time error after upgrade
First report below had me wondering if this was the locale-sensitive time parsing issue/fix:
Second report and my own testing on en-US GUI setting and CLI makes me doubt that.
My popup shows up when I open Restore in GUI, with or without restore-legacy true.
Interestingly, with GUI Commandline restore, whatever’s going wrong doesn’t happen.
Poking further with Export As Command-line, the help text for time gives me examples.
Duplicati supports absolute and relative dates and times:
now --> The current time
1234567890 --> A timestamp, seconds since 1970.
"2009-03-26T08:30:00+01:00" --> An absolute date and time. You can also use the local date and time format of your system like e.g. "01-14-2000" or "01 jan. 2004".
Y, M, D, W, h, m, s --> Relative date and time: year, month, day, week, hour, minute, second. Example: 2M10D5h is now + 2 months + 10 days + 5 hours.
All work in 2.1.0.111 restore with time option, as does the style posted above. 2.1.0.112:
now fail
1234567890 pass
2009-03-26T08:30:00+01:00 fail
2M10D5h pass
20250328T131220Z fail
I’m not testing for proper interpretation, just for whether ot not option value gets rejected.
It’s not like 2.1.0.111 lets in everything, but there seems to be two levels which might fail:
Restore started at 4/10/2025 10:35:24 AM
The value "wrong" supplied to --time does not represent a valid time
Checking remote backup ...
Listing remote folder ...
The operation Restore has failed with error: Unparsed data: wrong => Unparsed data: wrong
System.Exception: Unparsed data: wrong
at Duplicati.Library.Utility.Timeparser.ParseTimeInterval(String datestring, DateTime offset, Boolean negate)
at Duplicati.Library.Utility.Timeparser.ParseTimeInterval(String datestring, DateTime offset)
at Duplicati.Library.Main.Options.get_Time()
at Duplicati.Library.Main.Operation.RestoreHandler.PrepareBlockAndFileList(LocalRestoreDatabase database, Options options, IFilter filter, RestoreResults result)
at Duplicati.Library.Main.Operation.RestoreHandler.DoRunNewAsync(IBackendManager backendManager, LocalRestoreDatabase database, IFilter filter, CancellationToken cancellationToken)
at Duplicati.Library.Main.Operation.RestoreHandler.RunAsync(String[] paths, IBackendManager backendManager, IFilter filter)
at Duplicati.Library.Main.Controller.<>c__DisplayClass23_0.<<Restore>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at Duplicati.Library.Utility.Utility.Await(Task task)
at Duplicati.Library.Main.Controller.RunAction[T](T result, String[]& paths, IFilter& filter, Func`3 method)
at Duplicati.Library.Main.Controller.Restore(String[] paths, IFilter filter)
at Duplicati.CommandLine.Commands.Restore(TextWriter outwriter, Action`1 setup, List`1 args, Dictionary`2 options, IFilter filter)
at Duplicati.CommandLine.Program.ParseCommandLine(TextWriter outwriter, Action`1 setup, Boolean& verboseErrors, String[] args)
at Duplicati.CommandLine.Program.RunCommandLine(TextWriter outwriter, TextWriter errwriter, Action`1 setup, String[] args)
The complaint which has gotten touchy in 2.1.0.112 is the first style, maybe a pre-check.
EDIT:
I see I reported this myself here using an image, two weeks ago, but here’s more testing.