22

Hello,

is it possible to completely disable the automatic file type detection and solely go by the file extension (like in good old windows explorer )?

I find it really annoying that I can't sort by type in my matlab/octave projects folders, because the automatic file detection detects my m-files as sometimes objective-c, sometimes text, sometimes tex/latex etc.

They all end with .m, so sorting by extension would be much more useful for me (and probably faster as well). So is it possible to switch the automatic file type detection off and fall back to type detection by extension only?


Thanks!

As far as I am aware, this isn't possible, and is outside the control of KDE, as it simply depends on shared-mime-info providing reliable information.

Can you please provide the output of the following two commands?

Code: Select all

kfile4 -av <name of a matlab file>
file --mime-type <name of a matlab file>

bcooksley wrote:Can you please provide the output of the following two commands?

And also

Code: Select all

kmimetypefinder <name of a matlab file>

Thanks for the help,

output for file 1 (NGStore.m) shows as "Objective-C script" in dolphin:

Code: Select all

> kfile4 -av NGStore.m
kfile4: symbol lookup error: /usr/lib64/libldap-2.4.so.2: undefined symbol: ldap_int_tls_destroy

>file --mime-type NGStore.m
NGStore.m: text/plain

> kmimetypefinder NGStore.m
text/x-objcsrc
(accuracy 100)

File 2 (Trainer_BM_CD_Persistive.m) shows as "TeX document" in dolphin:

Code: Select all

> kfile4 -av Trainer_BM_CD_Persistive.m
kfile4: symbol lookup error: /usr/lib64/libldap-2.4.so.2: undefined symbol: ldap_int_tls_destroy

> file --mime-type !$
file --mime-type Trainer_BM_CD_Persistive.m
Trainer_BM_CD_Persistive.m: text/x-c++

> kmimetypefinder !$
kmimetypefinder Trainer_BM_CD_Persistive.m
text/x-tex
(accuracy 10)

File 3 (getTongaApproximation.m) shows as "MATLAB script" in dolphin:

Code: Select all

> kfile4 -av getTongaApproximation.m
kfile4: symbol lookup error: /usr/lib64/libldap-2.4.so.2: undefined symbol: ldap_int_tls_destroy

> file --mime-type !$
file --mime-type getTongaApproximation.m
getTongaApproximation.m: text/plain

> kmimetypefinder !$
kmimetypefinder getTongaApproximation.m
text/x-matlab
(accuracy 100)

And for a mat file, dolphin shows "plain text document":

Code: Select all

> file --mime-type data.mat
data.mat: application/octet-stream

> kmimetypefinder !$
kmimetypefinder data.mat
text/plain
(accuracy 5)

Should I worry about kfile4 not working?

Cheers,
Ben

flatfish wrote:Should I worry about kfile4 not working?

Not much, as kmimetypefinder uses the same method which is used all around in KDE, as you can notice as well by looking at its output with your files.

The problem is that in the case of Matlab files, just the extension is not enough, as also Objective-C sources have the .m extension. In this case also the content is used to try to get a better idea of the file type, but neither Objective-C nor Matlab files have a "fixed" structure which can easily be recognized.

What are the versions of your KDE libraries (kdelibs) and of shared-mime-info?

pinotree wrote:The problem is that in the case of Matlab files, just the extension is not enough, as also Objective-C sources have the .m extension.

Ah, didn't know that objective-c uses the .m extension. Well, I take it that some people also use .m for Latex or perhaps the extension isn't used at all for file type detection once the extension is considered ambiguous.

pinotree wrote:In this case also the content is used to try to get a better idea of the file type, but neither Objective-C nor Matlab files have a "fixed" structure which can easily be recognized.

I can imagine that this is difficult. That's why I was hoping for a hidden "sort by extension only" option. Since I don't have any objective-c and/or tex documents ending with .m (certainly not in the same folder), this low-tech solution should work well for me. But if there is no such option (trusting bcooksley's reply) then, well I'll live with that

pinotree wrote:What are the versions of your KDE libraries (kdelibs) and of shared-mime-info?

kdelibs4 is 4.4.4-2.5 (openSUSE 11.3 x86_64) and shared-mime-info is 0.71-4.1 (openSUSE 11.3 x86_64)

Cheers
Ben

Since it isn't currently possible, and apparently our finny friend thinks it would be nice if it were possible, I have moved this to brainstorm.

sorry to revive this old topic, but I had a few days ago a very similar discussion in kde buglist:
https://bugs.kde.org/show_bug.cgi?id=337804

Obvious should be that handling by mime type only is for filehandling inefficient especially when it comes to files from an OS like windows which usually relies on file extensions.
I really can't understand why an inefficient and also potentially faulty file recognition is preferred and an in this case simple and reliable solution is being discarded.
Don't get me wrong here, mime detection has a lot of advantages when it comes to open or edit files (and of course sorting for these purposes), but definitely not for sorting when it plain comes to copy files, especially under consideration that there are files which are the same mime type but having a different file extension nevertheless to distinguish them. It's a must fail situation for mime detection. Also the long delay for possible updates of shared-mime-info seems to be very questionable if really using dolphin in a productive environment or daily usage.

So I hope this brings this topic to attention again and this idea is considered.

+1. KDE could attempt to fix mime types for specific types of files, but there are just too many possible. I ran across this problem while trying to sort some DNA sequencing files, which are presumably a fairly obscure format. Nevertheless, they have consistent suffixes.

Code: Select all

$ ls Seq_1_SP6_C07.*
Seq_1_SP6_C07.ab1  Seq_1_SP6_C07.bn  Seq_1_SP6_C07.fa  Seq_1_SP6_C07.seq
$ file Seq_1_SP6_C07.*
Seq_1_SP6_C07.ab1: data
Seq_1_SP6_C07.bn:  ASCII text, with CRLF line terminators
Seq_1_SP6_C07.fa:  ASCII text, with CRLF line terminators
Seq_1_SP6_C07.seq: ASCII text, with very long lines, with no line terminators

As I understand it, the filename extension is considered when determining the type of the file; thus, it seems to me two different approaches have been suggested above:

1. A request for an option to determine the type based only on the filename extension, indirectly affecting the sort order in Dophin.
2. A request for an option to sort by the filename extension in Dolphin, irrespective of the determined type.

#1 seems to be pointless, since as noted the shared-mime-info database is not a perfect mechanism either, and where the filename extension is ambiguous, it would affect other operations through Dolphin.

#2 is perhaps more practical, though I would suggest it be implemented as a separate column (that is hidden by default). That would provide the sorting option without impacting other functionality, and would also take advantage of Dolphin's per-directory configurability for those who wanted to use it in specific places only.

That said, the best approach for all concerned is to keep improving shared-mime-info and the detection system, and to continue to encourage application authors to move to open standards and open specification file formats that can be reliably identified.

aexoxea wrote:#2 is perhaps more practical, though I would suggest it be implemented as a separate column (that is hidden by default). That would provide the sorting option without impacting other functionality, and would also take advantage of Dolphin's per-directory configurability for those who wanted to use it in specific places only.

This sounds the most logical to me.

aexoxea wrote:That said, the best approach for all concerned is to keep improving shared-mime-info and the detection system, and to continue to encourage application authors to move to open standards and open specification file formats that can be reliably identified.

As alluded to in my post above, this is not always easy. It's a good concept in theory, but there are so many obscure formats, it's much easier to allow sorting by suffix.

#2 would be a more than sufficient solution, wondering if there is some progress here finally after all these months...

Maybe just look for comment contains filetype at beginning of file? Matlab file isn't compiled, so we can provide our standards and maybe everyone will took it? People can by they own add mime-type information to beginning of matlab files and in future editors will add it by they own.

I also know, that there's open source editors for matlab file, so go ahead with adding comment with file type.

Lachu wrote:Maybe just look for comment contains filetype at beginning of file? Matlab file isn't compiled, so we can provide our standards and maybe everyone will took it? People can by they own add mime-type information to beginning of matlab files and in future editors will add it by they own.

Surely no bad idea, still doesn't solve the problem itself here, since never all files will have such a comment either.

Is there any progress right now or is it being ignored again as all the years before now? Sorry for being harsh, but this is open so damn long now and would be such an easy task. Staying with Krusader I suppose.