| Summary: | Cannot index and search files in soft link path using Baloo Desktop Search. | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-baloo | Reporter: | metalbrick <metalbrick> |
| Component: | Baloo File Daemon | Assignee: | baloo-bugs-null |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | CC: | andrew.crouthamel, aspotashev, b-misc, broken.zhou, bugzilla, cfeck, clodoaldo.pinto.neto, junkmailer, katyaberezyaka, kitts.mailinglists, lucas.olvr.campos, null, r.oosterhoff, sdarwin, tagwerk19, trebor_x |
| Priority: | NOR | ||
| Version: | 5.87.0 | ||
| Target Milestone: | --- | ||
| Platform: | Kubuntu | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=446715 https://bugs.kde.org/show_bug.cgi?id=447119 |
||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | screenshot of original and symlinked folder with and without metadata | ||
|
Description
metalbrick
2014-04-21 09:13:53 UTC
Since there is no other simple way to index selected directories outside /home, this indeed should work correctly. *** Bug 336315 has been marked as a duplicate of this bug. *** I have e.g. all my music files on a separate partition and only symlinked the folder /media/disk2partx/multimedia/music to ~/music. When I open the partition folder in dolphin all music information like artist, title length etc. is shown but the folder ~/music only shows size and date and does not offer any further information for the files to be shown in the tooltip or sidebar. I guess this also is because baloo is not capable of following symlinks. I have a lot of symlink folders in my home - and all are not indexed... I don't use the search feature of baloo - but I want to see all meta information of the files when hovering over them in dolphin... I follow a similar approach: Some data is shared between different users and symlinked into their $HOME folders. Not being able to easily use baloo for these links is a pity. Also using ratings or tags doesn't work like expected inside linked folders. Also think of users who move their video or music collection away from a SSD and onto a spinning disk: using symlinks integrate them into $HOME is nice, but baloo doesn't work as expected. Hi. I'm a little confused about the bug, and while I could investigate it more, It would be nice if one of you provide exact steps to reproduce this? There seems to be a mix between tag problems and searching not working through Dolphin? My approach: User A has /home/A User B has /home/B Shared between them is group AB, with ACLs and shared data in /home/AB/ Directories inside /home/AB/Documents/ are symlinked into /home/A/Documents and into /home/B/Documents, so the users don't have to switch to /home/AB/Documents, which is - as I think - a nice approach (think of a family, there are files and folders they may want to share). Baloo is configured to include /home/A and /home/AB for user A, /home/B and /home/AB for user B. Now what I discovered is that file search with krunner works very well and finds also shared files; it shows them with the path /home/AB/..., which is ok. Search in dolphin from inside /home/A/ finds it as well, but only if searching in "Everywhere"; "From Here" does not find the file (because the symlink is not followed during indexing, I assume). As far as the tags and ratings are concerned, it's pretty much the same: If A rates a file inside /home/AB/Documents/aFolder with dolphin, it works as expected, dolphin reacts immediately. But dolphin doesn't show the rating inside /home/A/Documents/aFolder_symlinked, where aFolder_symlinked is a symbolic link to aFolder. If A rates the file inside /home/A/Documents/aFolder_symlinked, dolphin takes a breath but remembers the rating; but inside /home/AB/documents/aFolder the rating is not shown. The same problems arises with the music and video collection, which resides inside /data/Music and /data/Video and is shared between users A and B as well, symlinked to e.g. /home/A/Music. There seems to be a sort of synchronization missing between the original files/folders and the symlinked ones which imposes problems in the way I described the sharing of files between the different users. Created attachment 89302 [details]
screenshot of original and symlinked folder with and without metadata
What you see here are the same files in virtually the same folder. On the left it is a subfolder in the folder /media/sda6/Fotos/ symlinked to ~/Fotos/ - on the right it's the folder not symlinked. The right sidebar shows the metadata collected by baloo for the chosen file dscn8824.jpg on the right in the original folder. In the pop-up on the left you see the same image's information in the symlinked folder - no metadata at all.
Though baloo has the metadata of the file it is not able to show it. I have symlinked a lot of folders from other partitions into my home - and none of them is usable with baloo (tagging, searching - and most important for me for images and mp3s: metadata information).
Git commit fcabb6a446cb7056d8128d68d60ce15cbd88702d by Vishesh Handa. Committed on 24/10/2014 at 15:40. Pushed by vhanda into branch 'master'. File: Always use the canonical path This should fix a part of the problem where Dolphin's Information Panel does not always show the correct information for system links. M +3 -3 src/lib/file.cpp http://commits.kde.org/baloo/fcabb6a446cb7056d8128d68d60ce15cbd88702d Hey Mau. Thanks for the detailed info. This makes the problem clear. It's not a trivial fix and I'm not exactly sure how to fix it right now, but I do understand the problem. Notes for myself / other developers - One possible way to solve this is to extend our current IdTree and IdFileName mappings. We currently map * IdFileName ---- <id> ---> <pid> fileName * IdTree ---- <pid> ---> <cid> <cid> ... pid = Parent Id cid = Child Id Instead of this mapping, we make the IdFileName map to multiple parent ids + fileName. This way one file (id) can have multiple parents. This way when doing a search for files under a particular sub-directory would just work as the IdTree would have both the mappings. Cases where this would not work - * If the systemlink has a different filename and you're searching for that * Keeping all these ids up to date. Another possible solution is to just not use the IdTree for when doing searches, and iterate over the entire file system structure manually. This could be very expensive though. Git commit eea16e6cd9ecdba9c26b870472cacb32b34187e2 by Igor Poboiko. Committed on 19/03/2017 at 21:13. Pushed by poboiko into branch 'master'. Search also in symlinked directories M +2 -1 src/lib/searchstore.cpp https://commits.kde.org/baloo/eea16e6cd9ecdba9c26b870472cacb32b34187e2 This has been reintroduced with the new version of Baloo and Dolphin from 4th of February 2021. In January it worked on my setup, which is a HDD mounted on /media and symlinks in the user’s /home folder to media folders on that /media (which is faster than the probably commoner setup of all /home being on a HDD, since user applications write their caches in /home), and after my updating my Arch in February I ceased to find anything via Dolphin’s Baloo search – due to my usual way of accessing those folders via “Documents”, “Videos” and so on being symlinks, I have found out this night, as I found that searching all indexed files worked, and then that the direct path on /media worked, but not the accustomed way. I was not using KDE at the time of Igor Poboiko’s message from 2017-03-19 referring to his fix, but apparently this issue has been fixed since then and comparing the recent code changes with his code – me not even being able to read programming code – this issue’s bug was reintroduced by Stefan Brüns in commit c6ade65a2ab8c206b5ae4f1c683f532b74a4c734 from 23rd of January 2021: https://invent.kde.org/frameworks/baloo/-/commit/c6ade65a2ab8c206b5ae4f1c683f532b74a4c734 Happening here on Kubuntu 21.10, Plasma 5.23.2 I know this has been open "long term" and I'm hesitant to step on any toes. There seem to be several different, confusing and messy behaviours associated with baloo indexing and dolphin searching in the context of symlinks and I've created a separate bug that summarises "the various" symlink troubles. This is Bug 447119 I think the issue here is covered by 447119 "Case 2a" and the "Wished For" results I'll flag this as a duplicate. If you feel that's wrong and I've missed or misunderstood something, please reopen this issue and append details. *** This bug has been marked as a duplicate of bug 447119 *** |