Restore-search results in folder nodes w/o names displayed

Support
1

Do you also get this eerie look of an empty folder tree when you search for files which do exist in a backup version? The folder tree expands the right way to show the matching files, but filenames and folder names are missing. Nontheless I can restore a file the blind way. Same with older snapshots, other backup configurations and other browsers.

I did not noticed this before I updated to v2.0.7.1_beta_2023-05-25.
Without a search term everything looks as usual with the folder names displayed, and restoring files works well.

Restore search results in foldernodes without foldernames displayed
Restore search results in foldernodes without foldernames displayed1200×928 51.8 KB

2

Hmm, here is the screenshot for 2.06:

206b
206b751×387 17 KB

And here it is for 2.07:

207b

not much of a regression to see IMO.

You can check (if you are interested) by using another computer, installing the old version, create a fake job, copy the database for your job, open a sql browser and update the database with:

update version set version = 11;

(as the database is functionally compatible there are only additional indexes that will not hinder the old version, it should work fine).

then restarting duplicati and trying out the restore web ui
You can do the same on your normal computer but it’s a bit more risky of course.

3

Thank you for checking, I trust you are right, no need to double check. Okay, so this is a known issue, which I did not notice before (it’s not so long that I startet with Duplicati). But then, I did’t find an open issue on GitHub, shall I open one?

My workaround would be to restore all files matching to a new path and then search the restored files. This would be space demanding with larger files, but in most cases, yes, why not :slightly_smiling_face:

4

There seems to be an implicit asterisk wildcard added before and after the query string by JavaScript:

I don’t search much, but when I do it’s usually for some file, so I just type the name (or a piece of it) in.

Omitting the leading asterisk seems to improve both searches. Oddly, a trailing asterisk doesn’t hurt it.

If anyone wants to try to read the JavaScript, see the link above.

5

and now that I’ve played with its behavior some, I did an issue search for in:title search and found

Search shows blank tree. #2682, where the commentary seems to be saying the same thing that I said.

6

Thank you for linking to the GitHub Issue.

And here is the explanation how the search function works by design:

The search function spans the full path including back slashes, and - for convenience - surrounds the search term with asterisks wildcards (as you told). Further wildcards can be used within the search term, while doubling asterisks leads to malefunction (at least in leading position). Alternatively RegEx can be used.

As long as this is observed search works without troubles.

To overcome the malefunction someone versed could try to eliminate any double asterisks (or any cumulation of wildcards) from the search phrase before it is applied.

7

You might be mixing different things. The citation talked about The FIND command not the GUI search.

Certainly it can with find. I’m a bit doubtful a GUI search would like it, knowing its insertion of asterisks.

FWIW a find doesn’t mind double leading asterisks. My JavaScript and GUI isn’t instantly up to finding where GUI search goes wrong, but interestingly its query sent to the server gives same path either way.

GET /api/v1/backup/4/files/*short.txt*?prefix-only=false&time=2023-06-14T04%3A20%3A02-04%3A00&filter=*short.txt* HTTP/1.1
  "Files": [
    {
      "Path": "C:\\Users\\<me>\\Documents\\size test 2\\short.txt",

GET /api/v1/backup/4/files/**short.txt*?prefix-only=false&time=2023-06-14T04%3A20%3A02-04%3A00&filter=**short.txt* HTTP/1.1
  "Files": [
    {
      "Path": "C:\\Users\\<me>\\Documents\\size test 2\\short.txt",

yet the display is different… Regardless, these are some clues a developer could use to debug further.
This might even be an HTML display phenomenon (even further from my expertise…). An initial search having an asterisk in front goes “Busy” for seconds and makes the odd tree. Deleting * fixes it instantly.

EDIT:

and developer tools Network activity shows it didn’t talk to the server, unless appearance is misleading.

Venturing into new territory for me (any good web devs around?), right-click on the folder part of icon to Inspect got me above something that changed from nothing to the expected text when I deleted the *.

Setting an Event Listener Breakpoint on Keyboard, pressing Delete on the *, and stepping looked like jquery.min.js is what put the text it, although I didn’t look very finely because I don’t know jQuery…

8

I made a fix for this (among other UI bugs):

The search function in the GUI only supports simple wildcards, not regex. The UI directly used regex for highlighting which causes an error because a leading asterisk is not valid, but the backend results were correct.

It did not even take that much tinkering, the console showed an error in the RegExp constructor as soon as the * was entered, so I only had to find where that is used (although the stack trace is confusing with angularJS).

2 Likes