Nemo: Wrong mimetype shown for empty files

[tpapastylianou]

```

• Nemo version (nemo --version): nemo 3.6.5
• Is issue with desktop or windowed nemo?: windowed
• Distribution - (Mint 17.2, Arch, Fedora 25, etc...): mint 18.3
• Graphics hardware and driver used: Radeon R7
• 32 or 64 bit: 64bit
  ```

Issue
This issue relates to this stackexchange post: https://unix.stackexchange.com/questions/426952/wrong-mime-type-displayed-for-empty-text-files

In summary, when a file is empty, nemo shows text/plain as the mimetype in the "MIME Type" column, rather than the mimetype specified in the database for that particular glob. E.g. a .w file with a mime definition for .w files as text/w will show as text/w in nemo if it has contents, but as text/plain if it is empty.

Other relevant posts:

• https://unix.stackexchange.com/questions/283601/xdg-resolves-filename-as-text-plain?rq=1
• https://unix.stackexchange.com/questions/9856/why-does-xdg-mime-query-filetype-fail-to-find-a-new-added-file-type?rq=1

Steps to reproduce
See stackexchange post

Expected behaviour
The mimetype should show text/w rather than text/plain

Other information
Can someone confirm whether this behaviour happens because of nemo using xdg-mime query filetype to produce the output in the "MIME Type" column? If so, fixing this bug could involve relying on the output of the mimetype command instead, which produces the correct output.

[ranolfi]

It would appear that Nemo is not using xdg-mime, but instead, gio.

I'll try and make a patch for this.

[tpapastylianou]

@ranolfi have you had any luck with this?

[ranolfi]

Not yet, unfortunately I could not find the time and have also been dealing with a major health issue.

As I still intend to address this, I've set a reminder for next week.

Thanks for pinging me about the issue and please feel free to do that again in case I don't report back in 10 days or so.

[mtwebster]

Just some observations: This occurs in caja and nautilus as well (all use GIO,) and is reflected using gvfs-info on the given file. Using dolphin, it shows the comment in the xml file (curiously I can't find what it sees as the raw mimetype there, it may be it hides it for this reason.) Dolphin also uses a different toolkit altogether from the others.

I know mimetypes are sniffed out by checking content of a file - a file's extension does not necessarily lock it in to a specific mimetype (unlike Windows, for instance.) But I agree that a file with a particular extension, when all else fails (such as in the case of an empty file) should fall back to using its extension as the deciding factor. I'll dig a bit further when I get a chance.

[mtwebster]

Quite a bit of discussion here about this issue: https://bugzilla.gnome.org/show_bug.cgi?id=755795

The current glib implementation (that nemo and many other apps use) assigns text/plain to all zero-length files, regardless of extension.

See: https://github.com/GNOME/glib/blob/glib-2-48/gio/glocalfileinfo.c#L1241 - this is the current implementation on Mint 19.

I'd prefer to see the extension taken into account if it's a known extension, but I can appreciate all sides of the arguments made there.

g_content_type_guess() appears to get the correct mimetype regardless of whether the file is empty or not. I'll see if there's an appropriate and safe place to implement it in nemo. I'm a bit concerned about changing behavior like this but we'll see. (https://xkcd.com/1172/)

[tpapastylianou]

Thanks @mtwebster . If it's of any interest, the main reason I came across this 'bug' in the first place was because I was trying to sort "by extension", and this is not a sorting method that is supported in nemo, and empty files were sorted separately given the mimetype bug, hence the 'twin' post here: https://github.com/linuxmint/nemo-extensions/issues/258

Feel free to do with that post as you will, given the above, though in some other sense it is a separate issue (in theory a sorting group for 'extension' could be added separately which does not rely on mimetype as a sorting strategy).

As for what workflow this has broken, the other thing I was trying to do was associate a custom icon per extension via the mimetype glob approach, and clearly blank files (of which there are many) showed up without that icon. So, yes, I suppose xkcd is right here; this isn't a programmatic requirement, it's more of a visual one (I rely on the icons for grouping tasks effectively).

[mtwebster]

For what it's worth, sorting by "Detailed Type" (not visible by default) does a better job with sorting than just Type, as it goes a step further than just 'text file.' It's still not what you're requesting there, but it will display 'File of w type' in the column, for instance (after this commit,) matching the description in your custom mimetype definition. Custom icons should work as well via the definition file, though I didn't test this.