Files issueshttps://gitlab.gnome.org/GNOME/nautilus/-/issues2024-03-25T23:07:48Zhttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3368Search provider only shows "recent" files2024-03-25T23:07:48Zbrandon wrinkleSearch provider only shows "recent" filesSearching for a file using the shell search feature only returns files in the Recent file list.
Searching for a file in Nautilus/Files returns all relevant files, as expected.
# Affected Version
- Version: gnome-shell 45.3-2
- Versio...Searching for a file using the shell search feature only returns files in the Recent file list.
Searching for a file in Nautilus/Files returns all relevant files, as expected.
# Affected Version
- Version: gnome-shell 45.3-2
- Version: nautilus 45.2.1-4
- Distribution: Debian testing
- Also happens with development version: Installing org.gnome.NautilusDevel doesn't fix this
-
# Steps to reproduce
1. Super key
2. Type a known file
3. No Files results are returned
4. Open a file so it shows up in recents
5. Begin to type name of file in shell search
6. Search returns file as result, as expected
All default locations are enabled in the Search Locations dialog.
tracker3 index returns:
/home/bwrinkle/Desktop *
/home/bwrinkle/Documents *
/home/bwrinkle/Music *
/home/bwrinkle/Pictures *
/home/bwrinkle/Videos *
/home/bwrinkle -
/home/bwrinkle/Downloads -
This started happening on my Debian install within the last 6 months, probably much more recently.https://gitlab.gnome.org/GNOME/nautilus/-/issues/3365Opening Global Search from Other Places Makes Search Unresponsive to Query2024-03-14T15:48:44ZKhalid Abu ShawaribOpening Global Search from Other Places Makes Search Unresponsive to Query# Affected Version
- Version: main
- Distribution: Ubuntu 23.10
- Also happens with development version: Yes
# Steps to reproduce <!-- Explain in detail how the issue can be reproduced. -->
1. Open Other Locations
2. Open global search
...# Affected Version
- Version: main
- Distribution: Ubuntu 23.10
- Also happens with development version: Yes
# Steps to reproduce <!-- Explain in detail how the issue can be reproduced. -->
1. Open Other Locations
2. Open global search
3. Type a query in the search bar
# Expected Behavior
Search begins
# Actual Behavior
Nothing changes after typing in the search bar
# Additional Information
This was masked earlier by the temporary removal of Other Places before !1428.GNOME 46https://gitlab.gnome.org/GNOME/nautilus/-/issues/3360"Search Everywhere" button in remote locations takes me to local Tracker-back...2024-03-13T10:40:00ZJeff Fortin"Search Everywhere" button in remote locations takes me to local Tracker-backed search results, instead of offering temporary recursive searchWith the 46 / nightly version:
1. Make sure recursive search is disabled for remote locations in the preferences (default setting)
2. Open some `sftp://some_host/some_folder` location
3. Type-to-search something that is not present in t...With the 46 / nightly version:
1. Make sure recursive search is disabled for remote locations in the preferences (default setting)
2. Open some `sftp://some_host/some_folder` location
3. Type-to-search something that is not present in the directory you're looking at, but somewhere in its sub-directories
## Actual result
You are presented with this GUI:
![image](/uploads/e00eb87e7387a69fa2a258a05188ff65/image.png)
…but clicking "Search Everywhere" transforms your remote search query into a local Global Search query, which is a completely different context. Redirecting you to totally unrelated local search results is a bug, in my view.
## Expected result
I think it would make more sense to make the "Search Everywhere" button a "Search in Subfolders" button, with some sort of explanatory warning label above it that it might be slow.
Also as part of #3308 I would like the infobar to also allow temporarily recursive-searching a network location, even if there already are search results within the root folder.
What do you think @aday?https://gitlab.gnome.org/GNOME/nautilus/-/issues/3333Expose favorite folders to Overview search2024-02-26T03:37:45ZfortellerExpose favorite folders to Overview search# Affected Version
- Version: 45.2.1
- Distribution: Nobara 39
- Also affects development version: Don't know, it wouldn't start
### Use Cases
Hi. Thank you for your work! I mostly find Files to be a good file manager, but I miss bette...# Affected Version
- Version: 45.2.1
- Distribution: Nobara 39
- Also affects development version: Don't know, it wouldn't start
### Use Cases
Hi. Thank you for your work! I mostly find Files to be a good file manager, but I miss better integration with the rest of the OS. At least with favorite folders. When I add folders as favorites that's because I often have to go to those folders. Thankfully it's very easy to add and remove favorites, so I can always have my most used folders there.
When these are the folders I use the most, that also means it's the ones I want to open the fastest. But if I have multiple folders with the same name, the search in Overview never cares about my favorites and it gives me the same order of results every time, and I have to navigate down past the folders I never open to get to the one I open all the time. And if I have multiple folders starting with the same letters, the Overview search does not guess that I want one of the favorite folders when I start typing, so I still have to type as many letters to find it as I would have to if it was not favorited.
Let's say I take a lot of screenshots and I want to look over them often and dragndrop the ones I need into something. Searching for "screenshot" in Overview only gives me search results from Files that are individual screenshot files, from years ago. If I have my folder named Screenshots in my favorites I would expect that to show up first. Just and example, there are tons of work situations where getting to some specific folders fast is advantageous. I'm sure that's why the fav feature exists at all.
### Available Workarounds
There are extensions that can put a menu of folders in the top bar, I don't know if you can navigate them with keyboard only. Other than that it's just the way mentioned above, I think.
### Difficulties
The usefulness of the Overview search is highly diminished. Instead of going directly from search to the folder I work with all the time I have to first open Files then either tab very far down the sidebar or move my hand to the mouse and click on the favorite folder. One thing is that this takes more time. Worse is that it seems so unintuitive and broken.
### Suggested Enhancements
In addition to exposing fav folders in search it would also be nice if one could add specific folders (favs or not) to the Dash.
Thanks again for all you do, and for taking the time to listen!https://gitlab.gnome.org/GNOME/nautilus/-/issues/3324Onscreen keyboard does not work with folder creation/editing.2024-02-22T17:58:13ZJustin CampoOnscreen keyboard does not work with folder creation/editing.# Affected Version
- Version: 43.2
- Distribution: Debian 12.5
- Also happens with development version: I can't install
# Steps to reproduce
1. Create new folder by right clicking
2. Right click rename folder, hit backspace to delete la...# Affected Version
- Version: 43.2
- Distribution: Debian 12.5
- Also happens with development version: I can't install
# Steps to reproduce
1. Create new folder by right clicking
2. Right click rename folder, hit backspace to delete last character of folder name
# Expected Behavior
1. You can enter the name of the folder with the onscreen keyboard
2. You will delete the last character of the folder name
# Actual Behavior
1. Onscreen keyboard does not display/there is no way to enter folder name without prompt disappearing
2. Onscreen keyboard closes and there is no way to edit existing folder namehttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3308Redesign search information2024-03-09T16:05:53ZAntónio Fernandesantoniof@gnome.orgRedesign search information# Current Design:
Ugly, intrusive pseudo-banner:
![image](/uploads/5c7136a6caef9888e58641950161875a/image.png)
* If recursive search is disabled for local folder, it says: `"Searching locations only"`
* If recursive search is disabled...# Current Design:
Ugly, intrusive pseudo-banner:
![image](/uploads/5c7136a6caef9888e58641950161875a/image.png)
* If recursive search is disabled for local folder, it says: `"Searching locations only"`
* If recursive search is disabled for remote folder, it says: `"Remote location — only searching the current folder"`
* As recursive search is always disabled in Other Locations, it says: `"Searching locations only"`
* As recursive search is always disabled in Network, it says: `"Searching network locations only"`
# New design:
https://gitlab.gnome.org/Teams/Design/app-mockups/-/blob/master/files/files-search-46.png?ref_type=headshttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3307Use a AdwBanner for the "searching locations only" disclaimer2024-02-06T20:01:15ZSam Hewittsnwh@gnome.orgUse a AdwBanner for the "searching locations only" disclaimerWould be nice if this disclaimer used the banner pattern to be consistent with other views.
![image](/uploads/f71c9fa738a3faa6c7e3cab1f0c9c8c3/image.png)Would be nice if this disclaimer used the banner pattern to be consistent with other views.
![image](/uploads/f71c9fa738a3faa6c7e3cab1f0c9c8c3/image.png)https://gitlab.gnome.org/GNOME/nautilus/-/issues/3306Global Search ("Search Everywhere") keyboard shortcut clears search results i...2024-02-16T16:07:43ZJeff FortinGlobal Search ("Search Everywhere") keyboard shortcut clears search results instead of refocusing & selecting the search queryThis is essentially the same request as #2819 that was fixed by @abu_shawarib, but to bring that safety & consistency to the Global Search as well: if I search for something globally, then defocus the searchbar (ex: by keyboard-navigatin...This is essentially the same request as #2819 that was fixed by @abu_shawarib, but to bring that safety & consistency to the Global Search as well: if I search for something globally, then defocus the searchbar (ex: by keyboard-navigating to some other widget in the UI, or selecting some of the search results), pressing the Search Everywhere keyboard shortcut(s) again should refocus the searchbar and preselect its contents (see issue 2819 for the detailed logic / reasons behind this).https://gitlab.gnome.org/GNOME/nautilus/-/issues/3303The "Search Everywhere" view shows AdwBanners from other places such as the P...2024-03-13T14:02:34ZAutomeris naranjaThe "Search Everywhere" view shows AdwBanners from other places such as the Public and Templates folders## Affected version
46.beta- d11909986
## Steps to reproduce
1. Go to Trash
2. Click in the "Search Everywhere" button from the sidebar
3. Search for something
4. Do step 2 for Public and Templates folders
## Seen behavior
The AdwBa...## Affected version
46.beta- d11909986
## Steps to reproduce
1. Go to Trash
2. Click in the "Search Everywhere" button from the sidebar
3. Search for something
4. Do step 2 for Public and Templates folders
## Seen behavior
The AdwBanners from step 1 and 4 will show in the search view. This looks very weird, specially with the trash AdwBanner that shows the "Empty Trash" button:
![Screenshot_from_2024-02-05_20-21-49](/uploads/8a46c670c7660d0d21cd7c0309145f79/Screenshot_from_2024-02-05_20-21-49.png){width=425 height=284}
The file above isn't in the trash.GNOME 46https://gitlab.gnome.org/GNOME/nautilus/-/issues/3302Opening an empty folder from current folder search does not change the view2024-02-29T23:12:10ZSebastian KellerOpening an empty folder from current folder search does not change the view# Affected Version
- Version: latest main from git (`568bcee071baf99e7aeb829e5f92192ba1809fe5`) but also affects 45.2.1
- Distribution: Fedora 39
- Also happens with development version: Yes
# Steps to reproduce <!-- Explain in detail h...# Affected Version
- Version: latest main from git (`568bcee071baf99e7aeb829e5f92192ba1809fe5`) but also affects 45.2.1
- Distribution: Fedora 39
- Also happens with development version: Yes
# Steps to reproduce <!-- Explain in detail how the issue can be reproduced. -->
1. Create a new directory called `test` in your home
2. Click the "Search Current Folder" button
3. Search for "test"
4. Double click the "test" folder
# Expected Behavior
Showing the empty folder view for the test folder
# Actual Behavior
The pathbar changes, but the view keeps showing the search results instead of the empty folder
# Additional Information
This does not seem to affect global search mode (the one recently introduced in main). Also when searching for the "Public" folder and opening it (assuming it is empty) shows the public folder info banner, but keeps showing the search results instead of the empty folder view (but not in 45.2.1).António Fernandesantoniof@gnome.orgAntónio Fernandesantoniof@gnome.orghttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3300Follow-up from "Explicit Global Search mode": clearer wording2024-02-09T01:49:34ZAntónio Fernandesantoniof@gnome.orgFollow-up from "Explicit Global Search mode": clearer wordingThe following discussion from !1428 should be addressed:
- [ ] @snwh started a [discussion](https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1428#note_1998480): (+3 comments)
> One more piece of feedback after giving this ...The following discussion from !1428 should be addressed:
- [ ] @snwh started a [discussion](https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1428#note_1998480): (+3 comments)
> One more piece of feedback after giving this another look over.
>
> I think the empty state could say more, as well as tie in a reason that the "Search Settings" buttons is there:
>
> > Find files and folders in all search locations. Change which folders are searched in Search Settings.
>
> And update the button text to say "Open Search Settings" to avoid it being misinterpreted as "search (verb) Settings"
>
> ![image](/uploads/b1aef9957e5989a25f667ac8e49b2e27/image.png)https://gitlab.gnome.org/GNOME/nautilus/-/issues/3292No way to know the location of a file/folder when searching in grid view2024-02-05T20:12:36ZNokseNo way to know the location of a file/folder when searching in grid view<!--
It's useful to know if the latest development version has the same shortcoming.
It can be installed alongside the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/setup )
2. ...<!--
It's useful to know if the latest development version has the same shortcoming.
It can be installed alongside the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/setup )
2. Copy and run the following command in the Terminal or Console app:
flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref
3. Launch the development version (normal Files logo with yellow and black stripes), e.g. with:
flatpak run org.gnome.NautilusDevel
-->
# Affected Version
- Version: 45.2.1
- Distribution: Fedora 39
- Also affects development version: Yes
### Use Cases
<!--
Describe concrete situations, from daily usage, in which this app isn't helpful enough.
Focus on what you want to do, not how it should be done, but do mention possible constraints.
-->
When searching for something in grid view is hard to know the file/folder location.
Especially if there are multiple files/folders with the same name in different places.
### Available Workarounds <!-- Can the goal be achieved with the current app version? -->
When searching in grid view you have to open each file/folder property window to know the location.
### Difficulties <!-- Why is the current experience unsatisfying? -->
Tedious to know each file location when searching in grid view. You have to switch to list view when searching if you want to know the path or open the properties.
### Suggested Enhancements <!-- Optional - the other sections are more important. -->
There should be a tool-tip for each file/folder with the path (only when searching)https://gitlab.gnome.org/GNOME/nautilus/-/issues/3189Starred items should show at the top of global/recursive search results2024-02-08T05:44:21ZJeff FortinStarred items should show at the top of global/recursive search resultsSomething that could make the Star System more meaningful to some users (like me) would be to have ⭐ items always pinned to the top of search results matches (when they are part of the matches).
Personally, I'd expect this to work for g...Something that could make the Star System more meaningful to some users (like me) would be to have ⭐ items always pinned to the top of search results matches (when they are part of the matches).
Personally, I'd expect this to work for global and recursive searches (i.e. not just when I'm in the home directory, but any other complex directory that has a bunch of subdirectories). It would alleviate just a tiny bit the pain I feel from not having "Sort folders first" respected for search since version 45.
---
To figure out the proper place to patch this in the search-related code, Antonio may have some special guidance to unlock The 5tory of the 5ecret 5tar 5ystem.https://gitlab.gnome.org/GNOME/nautilus/-/issues/3158Nautilus 45 search inconsistant behavior2023-11-21T02:32:08ZgetzzeNautilus 45 search inconsistant behavior# Affected Version
- Version: 45
- Distribution: ArchLinux
- Happens with development Flatpak: Yes
# Steps to reproduce
1. Open Nautilus
2. Start typing to search, only the files and folders that match the search are displayed.
3. Press...# Affected Version
- Version: 45
- Distribution: ArchLinux
- Happens with development Flatpak: Yes
# Steps to reproduce
1. Open Nautilus
2. Start typing to search, only the files and folders that match the search are displayed.
3. Press Esc to display all the files in the folder, the chosen file from search is now visible and selected.
4. Press Up or Down arrow to select next/previous file.
# Expected Behavior
Select the next/previous file in the folder.
# Actual Behavior
Navigate as if the first file in the folder had been selected: Select the second file in folder if Down and a no-go operation if Up.
# Additional Information
Another bad behavior is that the selected file before searching is lost and when deleting the search words, the first file of the folder is selected.
Also, after typing to search, if a file in a subfolder is selected and you press Esc, the chosen file is not selected (I assume because the current folder would have to change), but the first file of the folder (not the selected file before search). This is an inconsistent behavior.
Maybe Esc could be used to cancel the search (and go back to the previously selected file) and another shortcut (Shift+Enter ?) for selecting the chosen search result, even in a subfolder, and go back to the whole folder view.https://gitlab.gnome.org/GNOME/nautilus/-/issues/3084Nautilus search provider doesn't search in all indexed files.2023-09-16T21:40:34ZKarol Ochman-MilarskiNautilus search provider doesn't search in all indexed files.
# Affected version
- Nightly flatpak: Can't test it because I am not competent enough to do that.
- Other:
* version 42.2 of "Files" application (nautilus?)
* version 43.2 of Gnome
* Nixos version 22.11
# Steps to reproduce
<!--...
# Affected version
- Nightly flatpak: Can't test it because I am not competent enough to do that.
- Other:
* version 42.2 of "Files" application (nautilus?)
* version 43.2 of Gnome
* Nixos version 22.11
# Steps to reproduce
<!--
Explain in detail the steps on how the issue can be reproduced.
-->
1. Configure file search provider through gnome settings to recursively index HOME. This is achieved navigating to settings/search/search-locations and using "+ Add location". Alternatively set dconf setting "org/freedesktop/tracker/miner/files/index-recursive-directories".
2. Use the gnome search (system wide search accessed usually with "super key") typing a file name of a file found at depth >1 in the HOME directory. (File cannot be in 'recent' files for the reproduction).
# Current behavior
<!-- Describe the current behavior. -->
Search fails to find the file.
# Expected behavior
<!-- Describe the expected behavior. -->
Search finds file.
# Additional information
The recommended way to influence the Gnome/Files search provider is through settings/search/search-locations.
1. There's seemingly problems with that settings tab.
- Different switches in the same one view (like "Pictures" and "Home") influence different settings "index-recursive-directories" or "index-single-directories".
- For some reason the directory "/home/user" cannot be selected for being searched in the "Others: Add location" option.
2. The tracker settings (like `org/freedesktop/tracker/miner/files/index-recursive-directories`) don't actually influence search provider behavior. Seemingly it never searches recursively, but always searches single directories of "Recently opened", "Pictures", "Home" etc. Either way - the search space is fixed and not influenced by the settings.
So in my view 2. is a big limitation, especially given no alternative file search providers among gnome extensions.
Therefore my questions are:
- Is there another setting controlling the search provider?
- If the search provider is not configurable, would it make sense to put this feature onto the roadmap?
Thanks!
<!-- Ignore the text under this line. -->https://gitlab.gnome.org/GNOME/nautilus/-/issues/3062View never can reload after exiting search in large folders (freeze due to ex...2024-03-28T03:46:30ZCorey BerlaView never can reload after exiting search in large folders (freeze due to exponential filesystem queries)# Affected version
- Nightly flatpak: Yes
- Other: every previous version
# Steps to reproduce
<!--
Explain in detail the steps on how the issue can be reproduced.
-->
1. Open a folder with 100,000 files
2. Switch view from list to ...# Affected version
- Nightly flatpak: Yes
- Other: every previous version
# Steps to reproduce
<!--
Explain in detail the steps on how the issue can be reproduced.
-->
1. Open a folder with 100,000 files
2. Switch view from list to grid or grid to list
3. Alternatively (instead of step 2), search for something and leave the search by hitting escape
# Current behavior
<!-- Describe the current behavior. -->
The view never loadshttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3036Segfault in nautilus_files_view_set_selection2023-12-14T21:54:13ZSidSegfault in nautilus_files_view_set_selectionOn `nautilus-44.2.1`:
### Steps to reproduce:
Not sure about the steps to reproduce the crash. But I was doing "Search", doing a copy and traversing the view with `Alt + <-` and `Alt + ->`
```
Thread 1 (Thread 0x7f9b4485f040 (LWP 6802...On `nautilus-44.2.1`:
### Steps to reproduce:
Not sure about the steps to reproduce the crash. But I was doing "Search", doing a copy and traversing the view with `Alt + <-` and `Alt + ->`
```
Thread 1 (Thread 0x7f9b4485f040 (LWP 680202)):
#0 g_type_check_instance_is_fundamentally_a (type_instance=type_instance@entry=0x56526e08d5b0, fundamental_type=fundamental_type@entry=0x50 [GObject]) at ../../../gobject/gtype.c:4166
#1 0x00007f9b46a84efe in g_object_ref (_object=0x56526e08d5b0) at ../../../gobject/gobject.c:3775
#2 0x00007f9b476fec6b in g_list_copy_deep (list=list@entry=0x56526b6a1950 = {...}, func=0x7f9b46a84ef0 <g_object_ref>, user_data=user_data@entry=0x0) at ../../../glib/glist.c:764
#3 0x0000565266ce3651 in nautilus_files_view_set_selection (nautilus_files_view=<optimized out>, selection=0x56526b6a1950 = {...}) at ../src/nautilus-files-view.c:3263
#4 0x0000565266c87a59 in load_new_location (self=0x56526851a310 [NautilusWindowSlot], location=<optimized out>, selection=0x56526b6a1950 = {...}, file_to_activate=0x0, tell_current_content_view=<optimized out>, tell_new_content_view=<optimized out>) at ../src/nautilus-window-slot.c:2077
#5 0x0000565266c89e18 in setup_view (self=self@entry=0x56526851a310 [NautilusWindowSlot], view=view@entry=0x56526de47090) at ../src/nautilus-window-slot.c:2010
#6 0x0000565266c8a55a in got_file_info_for_view_selection_callback (file=0x56526aba7e90 [NautilusVFSFile], callback_data=0x56526851a310) at ../src/nautilus-window-slot.c:1869
#7 0x0000565266d07ab2 in call_ready_callbacks_at_idle (callback_data=0x56526b4992c0) at ../src/nautilus-directory-async.c:2010
#8 0x00007f9b477034c9 in g_main_dispatch (context=0x565267ca2a00) at ../../../glib/gmain.c:3460
#9 g_main_context_dispatch (context=context@entry=0x565267ca2a00) at ../../../glib/gmain.c:4200
#10 0x00007f9b477038e8 in g_main_context_iterate (context=context@entry=0x565267ca2a00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:4276
#11 0x00007f9b4770397c in g_main_context_iteration (context=context@entry=0x565267ca2a00, may_block=may_block@entry=1) at ../../../glib/gmain.c:4343
#12 0x00007f9b46baa34d in g_application_run (application=application@entry=0x565267c8d410 [NautilusApplication], argc=argc@entry=2, argv=argv@entry=0x7fff88e70678) at ../../../gio/gapplication.c:2573
#13 0x0000565266c7878b in main (argc=2, argv=0x7fff88e70678) at ../src/nautilus-main.c:81
```
<!-- Ignore the text under this line. -->https://gitlab.gnome.org/GNOME/nautilus/-/issues/2970Search: filter popover needs improvement2024-02-09T09:19:05ZAllan DaySearch: filter popover needs improvementThe current search filters popover looks like this:
![image](/uploads/24d22c3a8bb0c65396ed392e81ba33f2/image.png)
The available filters aren't initially visible, and you have to dig into the UI to add one. That makes it uninviting and ...The current search filters popover looks like this:
![image](/uploads/24d22c3a8bb0c65396ed392e81ba33f2/image.png)
The available filters aren't initially visible, and you have to dig into the UI to add one. That makes it uninviting and slow to use.
There are various other issues - the styling doesn't match modern conventions, the buttons that expand to lists are non-standard and a little surprising, the toggle doesn't represent FTS *and* file name matching, etc, etc
I recently came up with a new version of the popover, which addresses these issues:
![image](/uploads/a81b5b9a8e760d8960fad513b6305efc/image.png)
It's possible to add a filter with a single click, and it offers a nice "menu" of available filters. More details can be found in the [latest search mockups](https://gitlab.gnome.org/Teams/Design/app-mockups/-/blob/master/files/files-search.png).https://gitlab.gnome.org/GNOME/nautilus/-/issues/2963Files search does not work for some files2024-03-24T15:16:44ZJulien FalqueFiles search does not work for some filesFile search in Gnome Activities or using Files' search bar seems to fail for some files. For example, I have a file at `/home/julien/Documents/signature.png` but the search can't find it.
`tracker3` finds it:
```console
❯ tracker3 searc...File search in Gnome Activities or using Files' search bar seems to fail for some files. For example, I have a file at `/home/julien/Documents/signature.png` but the search can't find it.
`tracker3` finds it:
```console
❯ tracker3 search signature.png
Results:
file:///part/data/Users/Julien/Documents/signature.png
signature.png
```
But a D-Bus call doesn't:
```console
❯ gdbus call --session --dest org.gnome.Nautilus --object-path /org/gnome/Nautilus/SearchProvider --method org.gnome.Shell.SearchProvider2.GetInitialResultSet '["signature.png"]'
(@as [],)
```
`tracker3` returns a different path because `/home/julien/Documents` is a symlink to `/part/data/Users/Julien/Documents`, which is on a separate NTFS partition, could this be the culprit?
I'm on Arch Linux with Files v44.1.https://gitlab.gnome.org/GNOME/nautilus/-/issues/2452Matroska (mkv,mka) files are excluded by the "Video" and "Music" search filte...2024-01-18T15:43:10ZCharles WightMatroska (mkv,mka) files are excluded by the "Video" and "Music" search filters respectively# Affected version
- Nightly flatpak: Yes
- Other: nautilus-41.2 on opensuse Leap 15.4
# Steps to reproduce
1. Use a nautilus search term that will match both mkv and mp4 files (or mka and m4a)
2. Apply either the "Video" or "Music" se...# Affected version
- Nightly flatpak: Yes
- Other: nautilus-41.2 on opensuse Leap 15.4
# Steps to reproduce
1. Use a nautilus search term that will match both mkv and mp4 files (or mka and m4a)
2. Apply either the "Video" or "Music" search filter
3. Matroska files will be removed from the search results view
# Current behavior
If searching a directory with with various video and/or audio formats and the built in "Video" or "Audio" filters are used, matroska video and audio file (mkv,mka) are excluded from the search results.
# Expected behavior
Matroska video files should match with the "Video" filter just as mp4, wmv, avi, etc ...
Matroska audio files should match with the "Music" filter just like m4a, aac, wma, etc ...
# Additional information
The fix appears to be as simple as adding the mime types video/x-matroska and audio/x-matroska under the "Video" and "Audio" sections of nautilus-mime-actions.c. I have not tested it.
<!-- Ignore the text under this line. -->Corey BerlaCorey Berla