https://bugs.kde.org/show_bug.cgi?id=394750
Igor Poboiko <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from Igor Poboiko <[email protected]> --- Could you(In reply to Thaddee Tyl from comment #0) > If that large folder and the iso are the files that baloo_file chokes on, > could we make Baloo give up if it spends more than 10 seconds on a single > file or folder? (An `ls` on the Go games folder takes 11 minutes.) I guess in that case Baloo does can choke on this directory. And, I guess, this setup is indeed somewhat unusual. I suggest adding this folder to "exclude" list (it's available inside "systemsettings", in "Workspace -> Search -> File Search" category. Does this Go game files have a special mime-type? We have a list of blacklisted mimetypes inside Baloo (which currently includes mostly source-code files), we can blacklist it by default (as it hardly contains useful information for indexing, right?) > Philosophically, it makes more sense to whitelist files by type than to > index files that are unlikely to be properly read. Looking through the > configuration parameters, it looks like files are blacklisted by type. It > would make more sense to whitelist them: there are more file types that are > unreadable than there are supported ones. Most users only care about > indexing of .pdf, .docx and .jpg files, maybe a handful of others. I don't > see a use-case for indexing an .iso file. Yet it is neither in > excludeFilters nor in excludeMimetypes by default. Baloo relies on KFileMetaData framework to index files: if we can extract data from file, we do it. But it only supports use-cases relevant for users (documents, pictures, audio files, etc.). I'm not really sure iso-files are being indexed at all, as KFileMetaData does not support them (well, because there is not much to be extracted that is relevant for user...). > Aside. Is Baloo indexing file paths themselves? It would be both pretty > inefficient and a duplication of effort, since mlocate does it stellarly and > yet unnoticeably. /var/lib/mlocate is 98 MiB and `locate *.pdf` takes about > a second to run. It does. Also, Baloo is supposed to be self-sufficient, it's not supposed to be used together with mlocate, it's a separate indexing system. > Finally, when Baloo does pointless busywork, it would be welcome to have > more debugging tools. > balooctl could have a command to debug what baloo_file is currently indexing. "balooctl monitor" does that. (well, unfortunately it was not possible to print _current_ file being indexed, but this will be fixed in 5.52 release, see https://cgit.kde.org/baloo.git/commit/?id=a9696978322c08d19ece0a67f430aee391e3918d) -- You are receiving this mail because: You are watching all bug changes.
