https://bugs.kde.org/show_bug.cgi?id=432717
--- Comment #11 from David Palacio <c...@palacio.io> --- (In reply to Stefan Brüns from comment #10) > Because globs are to ambiguous. Globs *may* be ambiguous but not always and usually not. This is taken into account in the instructions I referred to in my previous comment. > Just because you have an entry in the > mimetype database which says *.dsf is some format it does not mean *all* > files with an dsf extension adhere to this format. It *may* be a file from > DAZ, it may be something completely different. How is this a problem? Having the type defined in SMI doesn't eliminate this potential problem. In fact, if the user database has the type defined with the correct subclass then, Baloo is already happy to discard this type as content indexable, as evidenced by comment #6. > Using globs only works only if the output is purely informational. Past > experience shows relying on globs is broken. Also note, the rationale for > using globs in the first place does not apply, as the indexer *does* open > the files anyway. This is wrong. I wonder if Baloo opens every single file in my home folder. It would be no surprise because it takes several hours to scan it. > The determined mimetype text/plain is completely correct - dsf files are > json files, which are a subclass or ecmascript, which is a subclass of > text/plain. > > If you want a different behavior, submit a proper mimetype to SMI. If I want a different behavior all I need to do is add a subclass to the type. It doesn't matter if the type is text readable, or a script, it has been shown that Baloo will ignore a type it doesn't know about even if it inherits text/plain. So what difference does it make if it doesn't inherit it? You say that Baloo should scan a file because it is text/plain but Baloo won't do it if it is a type that inherits text/plain. So what you are say is wrong or what Baloo does is wrong. -- You are receiving this mail because: You are watching all bug changes.
