test-filters error writes empty database named INVALID! to Duplicati current directory about duplicati

[Jojo-1000]

This might be a result of the new error reporting. The test command fails due to an error (not sure what caused yours, but shouldn't matter), but no DB to log it to. So when it tries, it will create that database.

Maybe try a test-filter in a folder that has no read permissions to reproduce.

Maybe we should check if the database exists first before logging the error.

[ts678]

Maybe try a test-filter in a folder that has no read permissions to reproduce.

That didn't do it, but invalid drive letter did. I also had Sysinternals Process Monitor watching for activity on that file name.
After second test below, I did another (not shown) and saw that for CLI it goes to my Command Prompt current directory.

C:\Duplicati\duplicati-2.0.7.100_canary_2023-12-27>Duplicati.CommandLine.exe test-filters C:\Windows\System32\config\
Including source path: C:\Windows\System32\config\
Error reported while accessing file: C:\Windows\System32\config\ => Access to the path '\\?\C:\Windows\System32\config' is denied.
Error reported while accessing file: C:\Windows\System32\config\ => Access to the path '\\?\C:\Windows\System32\config' is denied.
Including source path: C:\Windows\System32\config\
Error reported while accessing file: C:\Windows\System32\config\ => Access to the path '\\?\C:\Windows\System32\config' is denied.
Error reported while accessing file: C:\Windows\System32\config\ => Access to the path '\\?\C:\Windows\System32\config' is denied.
Including source path: C:\Windows\System32\config\
Matched 0 files (0 bytes)

C:\Duplicati\duplicati-2.0.7.100_canary_2023-12-27>Duplicati.CommandLine.exe test-filters Y:\Windows\System32\config\

System.IO.IOException: Backup aborted since the source path Y:\Windows\System32\config\ does not exist.  Please verify that the source path exists, or remove the source path from the backup configuration, or set the allow-missing-source option.
   at Duplicati.Library.Main.Controller.ExpandInputSources(String[] inputsources, IFilter filter)
   at Duplicati.Library.Main.Controller.<>c__DisplayClass31_0.<TestFilter>b__1(TestFilterResults result)
   at Duplicati.Library.Main.Controller.RunAction[T](T result, String[]& paths, IFilter& filter, Action`1 method)
   at Duplicati.Library.Main.Controller.TestFilter(String[] paths, IFilter filter)
   at Duplicati.CommandLine.Commands.TestFilters(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)

C:\Duplicati\duplicati-2.0.7.100_canary_2023-12-27>

[ts678]

The accident can be blocked by permissions. If I do a desktop icon start of 2.0.6.3 with a 2.0.7.100 upgrade, current directory is C:\Program Files\Duplicati 2\ so in this case it can't leave the errant file, even though Process Monitor shows that it's trying to...

EDIT:

This setup actually had 2.0.7.1 as its update before, but I switched Settings to Canary and got latest. Beta didn't have this bug.

[ts678]

The dbpath path set to INVALID! is really old, and seems unique to test-filters, which is why I updated the Issue title.

More generally speaking though, there are several CLI commands that don't intentionally involve a database, and there's a situation early on in the life of a server job where the database is assigned but there's not actually a database put there yet.

Commands that don't intentionally involve a database might get a dbpath anyway, if set up using the GUI Commandline.

I notice that there are some old issues talking about LogData, but I'm now also wondering how Operation table is handled.

Those are my thoughts on the general database issue. The goal for the new logging is probably to make no situation worse.

[ts678]

Despite good testing news from the desktop shortcut, this file breaks a service install running an update, by failing verification.

Windows service install/uninstall/start invalidates update by writing into it, causing version downgrade #5088 explains how so.
In the case here, the 2.0.7.100 that was running before could not come up on service restart. It downgraded to the next best.

EDIT:

Fortunately though, the fix of another install of 2.0.7.100, followed by a service restart, brings things back to where they were.