GNOME Bugzilla – Bug 792337
Can't index non-native directories
Last modified: 2021-05-26 22:24:48 UTC
It is not possible to index non-native directories (eg., gphoto2://.../) using IndexFile and IndexFileForProcess because tracker_indexing_tree_add expects everything to get resolved as a file:/// child. Directly indexing a non-native file works because it doesn't go through TrackerIndexingTree. One option is to special-case such locations as file:/// children. Even though g_file_has_prefix doesn't work across different URI schemas, conceptually, it still makes sense to think of a remote WebDAV mount or an attached camera as a child of file:///.
Created attachment 366504 [details] [review] libtracker-miner: Support indexing non-native directories
Created attachment 366505 [details] [review] tests: Add a test for indexing non-native directories
There is a similar issue in TrackerFileSystem, and GVfs doesn't like how TrackerFileDataProvider creates a GFileEnumerator through the synchronous API but uses it asynchronously later.
Created attachment 366547 [details] [review] libtracker-miner: Support indexing non-native directories
Created attachment 366548 [details] [review] tests: Add a test for indexing non-native directories
Created attachment 366549 [details] [review] libtracker-miner: Support caching non-native files
Created attachment 366550 [details] [review] tests: Add a test for caching non-native files
Created attachment 366551 [details] [review] libtracker-miner: Rename a variable for consistency
Created attachment 366552 [details] [review] libtracker-miner: Support enumerating non-native files
Review of attachment 366552 [details] [review]: Looks like it's even a cleanup :). Minor nit with the commit log, I think it would be clearer to make "avoid mixing sync & async enumerator API" be the subject (as it's the gist of the commit) and move the "fixes non-native files" into the blurb. ::: src/libtracker-miner/tracker-file-data-provider.c @@ +178,3 @@ + cancellable, + enumerate_children_cb, + g_object_ref (task)); Looks like this ref is being leaked in enumerate_children_cb(), I think there should be a g_object_unref after g_task_return* there.
Created attachment 367613 [details] [review] libtracker-miner: Don't mix sync & async GFileEnumerator APIs
Comment on attachment 367613 [details] [review] libtracker-miner: Don't mix sync & async GFileEnumerator APIs Looks good!
Comment on attachment 366551 [details] [review] libtracker-miner: Rename a variable for consistency From #tracker on GIMPNet: 10:57 <rishi> garnacho: Hey! I just realized that the async/sync FileEnumerator patch is on top of https://bug792337.bugzilla-attachments.gnome.org/attachment.cgi?id=366551 10:58 <rishi> It renames a variable. 11:04 <garnacho> rishi: hey :), makes sense 11:05 <garnacho> well, I guess it'll make more sense when remote locations are actually supported :p 11:05 <garnacho> but seems fine to have 11:07 <rishi> garnacho: The s/dir/url/ change is to just bring it in line with the sync implementation, and the public tracker_data_provider_begin* methods. 11:10 <garnacho> oh, indeed
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/tracker/-/issues/ Thank you for your understanding and your help.