Summary: | after baloo indexes some files more than once you can't clean this up | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-baloo | Reporter: | skierpage <skierpage> |
Component: | general | Assignee: | Stefan Brüns <stefan.bruens> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | baloo-bugs-null, dschridde+kde, moritzherrmann09+kde.org, nate, tagwerk19 |
Priority: | NOR | ||
Version: | 5.82.0 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
See Also: |
https://bugs.kde.org/show_bug.cgi?id=438528 https://bugs.kde.org/show_bug.cgi?id=401863 |
||
Latest Commit: | Version Fixed In: |
Description
skierpage
2021-06-10 03:33:56 UTC
(In reply to skierpage from comment #0) > Some baloo searches return the same file numerous times. The filesystem you are using is critical here, have a look at: https://bugs.kde.org/show_bug.cgi?id=402154#c12 Try checking the file with "stat" to see whether the device number / inode is "stable" across reboots. Baloo relies on the device number / inode internally, if a file appears with a different ID, it's treated as a different file. > ... make it appear N+1 times by deleting it on-disk and copying a backup Maybe NTFS mounts don't have stable ID's. That would be an extra indication... > Once this happens it seems impossible to clean up. Yes, I have also noticed this. It seems that a file has to be "there" on disc for "balooctl clear" to work and also (maybe?) the stored device number / inode also has to match. It's worth following up. > ... the behavior that deleting a file doesn't remove it from Baloo's index > happens on an ext4 volume as well... There are certainly times it doesn't, but I think mostly it does. It seems to be an issue "referred to" under different bugs, might be something of interest under Bug 353874, Bug 429006 and Bug 437754 (In reply to tagwerk19 from comment #1) Thanks for responding 🤗. > (In reply to skierpage from comment #0) > > Some baloo searches return the same file numerous times. > ... > Baloo relies on the device number / inode internally, if a file appears with > a different ID, it's treated as a different file. Ding-ding, that's it. `baloosearch --id term` shows different IDs for the same path, e.g. % baloosearch --id FuelCellWorks 500d900000803 /media/Windows/Users/spage/Documents/ECO.txt 5be2000000803 /media/Windows/Users/spage/Documents/ECO.txt 8546e00000803 /media/Windows/Users/spage/Documents/ECO.txt ... > > Once this happens it seems impossible to clean up. > Yes, I have also noticed this. It seems that a file has to be "there" on > disc for "balooctl clear" to work and also (maybe?) the stored device number > / inode also has to match. It's worth following up. I filed bug 438527 , and may have spotted a logic error in `balooctl clear` 😻. I filed enhancement bug 438528 to add a `balooctl remove [ID...]` subcommand. (In reply to skierpage from comment #2) > Thanks for responding 🤗. Thank you for taking the trouble to troubleshoot :-) Could be that it'll take some time to clear baloo bugs. I just do checking and sorting. I don't think you'd be treading on toes if you submitted a patch... Anyway, I'll flag as Confirmed... (In reply to skierpage from comment #0) > ... all on a mounted NTFS volume ... > ... Restoring the deleted file (I copied the backup back to it) adds > another copy of it to Baloo's index ... Without running tests on an NTFS disc, that sounds like you get a new inode with every copy. That is going to give baloo trouble... |