Why is the diagnosis for an empty file ‘application/x-zerosize’?
This is very strange.
The same file a.ini gets two different mimetypes just because of the different file sizes.
If a file has zero size then the magic detection is inherently impossible. The x-zerosize MIME type is meant to signal that information.
The other MIME type is determined by the extension, but like every check on a file name, it’s inaccurate; that’s why you’re supposed to check for the file name first, and the content after that.
2 Likes
Magic detection should be the last step.
When I renamed libgio-2.0.so.0.8200.2 to libgio.desktop.
The content type given by gio info is application/x-desktop。
However, the file is not application/x-desktop in nature.
So gio will use mime globs to match the file suffix.
So why is there a special treatment for empty files?
But the user defines the mimetype for the specified suffix.
You cannot ignore the user definition just because the file size is zero.
Even opening an empty file of unknown type should result in an error. Instead of editing it with a text editor as x-zerosize type.
The file suffix should be used as an accurate judgment. Because the user or program knows what the file is.
Even if the program opens the wrong file, a warning will pop up due to parsing errors. This is an expected error.
For opening files without suffixes, magic detection should be used.
For desktop environment users. For files without suffixes. Because you don’t know what they are, you don’t want to open them.
At this time, magic detection should be used. And provide corresponding icons. So that users know what the file is.
In short, respect the file suffix.
application/x-zerosize is defined by the XDG shared-mime-database, so it’s not something Gnome controls.
Creating empty files is anyway pointless. The only meaningful usecase I know is for .keep files, to preserve their parent folders.
If some application creates empty files leftovers, then it’s probably a bug of that app.
Whether this makes sense is up to the user.
Better to make sense than to make no sense.
I create a new file, double-click it, and expect the appropriate program to open, not a text editor.
If this question were to be voted on, I’m sure respecting suffixes would be overwhelmingly in favor.
Empty files make no sense. So is returning x-zerosize reasonable? Or does it make sense?
Reasonable and meaningful is: if a corresponding mimetype exists for the suffix, return it. Otherwise return x-zerosize.
If I understand correctly.
According to the spec.
“information from directories lower in the list takes precedence.”.
refers to ~/.local/share/mime.
My *.ini definitions are in ~/.local/share/mime/packages.
Why is that definition not matched first, and the definition in /usr/share/mime/packages/freedesktop.org.xml is used instead?
I want to ask a question.
Is there any specification that clearly states that x-zerosize should be returned when encountering an empty file?
I did not find any record in Shared MIME-info Database.
I also did not find the address of the https://gitlab.freedesktop.org/xdg/shared-mime-info repository.
I don’t know where to look for the specification.
Was there some kind of common knowledge before this?
The x-zerosize definition is here: https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/master/data/freedesktop.org.xml.in?ref_type=heads#L4755
I haven’t found anything either…
Regarding the detection based on content vs. detection based on globs, there was a spec somewhere mentioning that the resolution order is not defined and is at the applications discretion, because they may have specific reasons to prefer one or the other method.
In general, the current Gnome behavior doesn’t seem bad to me.
For example, what about an empty *.png file? Trying to open it with an image viewer/editor is pointless and will definitely fail, so application/x-zerosize totally makes sense in that case.
That said, that could be interesting if for specific cases we could override this behavior.
Hmm… that I don’t know, would be better to ask freedesktop people.
Empty files should be considered corrupt/erroneous.
I accept this prompt instead of opening a text editor.
Should not interfere with the processing of the program.
If I want to create a strange program now.
For example, I define the suffix:
.kill-p:application/x-kill-p
.start-p:application/x-start-p
and set the default handler.
I need to double-click to open to get the desired result.
But now, I have to edit the file content first. Make it not empty.
Then it can work properly.
The possibilities are completely limited at present.
You can think that this program is poorly designed.
A good operation should be to open the target program and then select the directory.
For empty files, return the real suffix. It will not cause any impact.
If you like text editors, you can select the corresponding open method through the right-click menu.
I am not opposed to returning x-zerosize for unknown suffixes and empty content.
Just to be sure: you want to open those empty files from Nautilus or similar files managers, right?
There may be a possibility with a small launcher wrapper, that you can register to open application/x-zerosize mimetype. This wrapper will then lookup for an appropriate application using the globs-only heuristics, and re-launch the file with the appropriate app.
Responsibility transfer.
If I had to choose a program based on the suffix, I wouldn’t post this discussion.
Because all programs read the glob file and match it by themselves. There is no unified interface.
End of discussion. Nothing makes sense.
Only Linux desktops are so messy.
I believe. When the market share of Linux desktops continues to increase. Until a threshold is reached.
When the number of people who encounter this chaos reaches a certain level, someone will eventually change this mistake.
I’m very sorry that I’m complaining here.
Because I encountered another puzzling problem recently.
It’s really hard for me to understand that Nautilus can’t create new files. Only folders can be created!