Files are classified only based on content type

Expected behaviour

Figuring out the file type should include the extension. There are a number of scenarios that do not make sense.

Having files of different types that are all empty be classified as the same type is weird and unpractical.
You probably never want to edit MP3 files with your editor. Having the same association for the program to open as a text file is wrong.
Not opening files with the same extension with the same program is inconsistent.

Actual behaviour

The content type of files is just based on the content type. The recent changes in glib related to application/x-zerosize are correct but have revealed this issue to me.

Steps to reproduce the behaviour

Create empty files with different extensions and navigate to the folder with caja. Open the properties for each file or try to open them.

MATE general version

1.26.1 but it may also occur in older and newer versions.

Package version

1.26.1-1

Linux Distribution

Archlinux

Link to bugreport of your Distribution (requirement)

There is none and this is a general issue.

First, I don't think this is a MATE or Caja issue, but if anything, a shared-mime-info, GIO or other lower-layer one (unless there's API to use in e.g. GIO to use a fallback MIME type in case the "main" one is "too generic" and that we don't use it).

Anyway, there's a few points I don't agree on:

Having files of different types that are all empty be classified as the same type is weird and unpractical.

Do you have examples with actual files? E.g. an empty file is never gonna be a MP3, OGG or actually, about none of the non plain-text formats (but even plain text sometimes cannot be empty, like e.g. XML), and very few empty files really carry much meaning (they are always gonna be more or less placeholders in the best case).

For example, let's take foo.mp3 with a size of 0 (wholefully empty): it is NOT an MP3 file: it doesn't conform with that file format. No tool that manipulate MP3s will be able to do anything with it, nor should they.

The only cases where it makes sense is for types where an empty file is at least not totally wrong, although usually not useful, and MP3 isn't one of them.

You probably never want to edit MP3 files with your editor. Having the same association for the program to open as a text file is wrong.

Well, they shouldn't be associated with the same MIME type, so they should not be associated with the same program unless:

there is a misconfiguration on your system (definitely on mine, a valid MP3 doesn't try to open in my text editor)
you have a program that can legitimately handle both plain text and MP3s for some reason (emacs? OK, that was a troll)

Not opening files with the same extension with the same program is inconsistent.

No, what's inconsistent is having files with different content types sharing the same extension. If I rename foo.mp3 to foo.pdf I don't expect the file to magically transform from music to textual document. See, point of view matters.

Anyway, if you only talk about empty files, maybe indeed it would make sense for the extension to weight more on content type detection, but it's clearly not as simple as "just use file extension to show content type", which is just wrong in so many cases. And I'm still wondering what actual use case there is for empty files to cause so much trouble.

mate-desktop / caja