SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Create /a and /a/b 2. Symlink /a/c -> /a/b 3. "Index" /a 4. "Ignore" /a/c OBSERVED RESULT /a/b is indexed. EXPECTED RESULT /a/b and /a/c should both be ignored. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: YES (available in About System) KDE Plasma Version: 5.25.2 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.5 ADDITIONAL INFORMATION
(In reply to Rohitt Vashishtha from comment #0) > OBSERVED RESULT > > /a/b is indexed. When you say "ignore" in step 4, you are indexing "a" and have added "a/c" to baloo's list of "excluded" folders? If I do the same, I see baloo indexing the contents of "a/b" (can confirm with "balooshow" and a testfile in folder b) but baloo does *not* follow symlinks when indexing so it does not "dig down" into a/c (see the Summary Bug 447119). Baloo keeps track of files 'via' their device/inode numbers and tries to keep a one-to-one relationship between this internal ID and the filename. A search, by default, gives results for the canonical filename. In this situation, adding an exclusion for a/c is not going to mean anything to baloo. So, I also see your "Observed Result" but I'm not sure I would expect your "Expected Result" (and I think it would lead to even more confusion and wierd edge cases as per Bug 447119)
I suppose that's ultimately a design decision you folk would have to make here. My usecase happened to be something like this: I have an old HDD that I had some git projects on that have tons of small files, including a clone of linux kernel. Now, for ease of access, I'd mounted that old HDD to /home/username/data-drive and then symlinked /home/username/gitclones to /home/username/data-drive/gitclones (along with other similar symlinks. I naturally decided I didn't want Baloo indexing these files, so I made it ignore the symlink and it didn't behave as I expected (by design, as you explained).
(In reply to Rohitt Vashishtha from comment #2) > I suppose that's ultimately a design decision you folk would have to make here. Ideally baloo should better "understand" symlinks but it would be quite an extra bit of complexity :-/ > ... so I made it ignore the symlink and it didn't behave as I expected ... I assume all worked OK when you excluded /home/username/data-drive/gitclones? (although you might have needed to purge and reindex to get rid of the info that baloo had already indexed). If that worked, I'll close the issue...
Sorry for the late reply. Yeah, that worked for me but I'm treating is as a workaround. I'll close this issue, but hope you keep this use-case in mind in case Baloo undergoes some internal restructuring later.