So I had to uninstall the ppa version of Xournal and build from source (with a modification). And now .xoj files open automatically with KDE's archive manager Ark, and are identified as being of type "Gzip archive" when one selects Properties from the right-click menu in Dolphin:
(Before, .xoj files opened with Xournal and were correctly identified.) This state of affairs persists despite all of the following:
1) Copied these files that come with the source package:
xournal.xml into /usr/share/mime/packages/
xournal.desktop into /usr/share/applications/
x-xoj.desktop into /usr/share/mimelnk/application/
2) added the line
3) added the MIME type
application/x-xoj in the File Associations System Setting
(with appropriate content):
(Note also that
application/x-gzip specifies only the .gz extension:
xournal.xml to /usr/share/mime/application
as suggested here
sudo update-mime-database /usr/share/mime
6) restarted the computer
edited to add:
7) [right-click an .xoj file] --> Open With --> Other... --> [select 'Xournal'], tick 'Remember application association for this type of file' also has no effect.
end of edit
This is on Kubuntu 12.04.
So, what am I missing?
Edited to add
I have discovered that the
file --mime-type [filename] and
mimetype [filename] commands produce different results, as in this question:
archelon@ingelrayok:~/Documents/xournal$ file --mime-type 2014-02-22-Note-02-09.xoj 2014-02-22-Note-02-09.xoj: application/x-gzip archelon@ingelrayok:~/Documents/xournal$ mimetype 2014-02-22-Note-02-09.xoj 2014-02-22-Note-02-09.xoj: application/x-xoj
However, there is no entry for
application/x-gzip in /etc/mime.types (from which the
file command supposedly gets its information); and, indeed, there shouldn't be, according to the comment at the beginning of that file, which reads in part:
Note: Compression schemes like "gzip", "bzip", and "compress" are not actually "mime-types". They are "encodings" and hence must not have entries in this file to map their extensions. The "mime-type" of an encoded file refers to the type of data that has been encoded, not the type of encoding.
That comment also says that
Users can add their own types if they wish by creating a ".mime.types" file in their home directory. Definitions included there will take precedence over those listed here.
There is at present no such file. There are some files in my home directory (which I didn't create) that are apparently related to the output of the
mimetype command; these include
~/.local/share/mime/types which contains only the text
In fact the directory ~/.local/share/mime/ and everything in it have the same timestamp (22:19 last night), and were thus presumably generated by the same process.
After looking at the manpages for mimetype and file, I decided to check the environment variables
$XDG_DATA_DIRS, which apparently are used by the former but not the latter. But I didn't know how to report the value of an environment variable, so I tried
cat $XDG_DATA_HOME, which set the value (to nothing) instead of reporting it. Edited to add: Or so I thought at first; actually it was already unset, as we shall see. The correct command is
echo $XDG_DATA_HOME, as I learned from reading about environment variables here. So then I discovered that
$XDG_DATA_DIRS was set to
/usr/share/default:/usr/local/share/:/usr/share/; the first of these doesn't exist. I don't think that matters, but anyway I ran the commands
to accord with the standard. I doubt that any of this will make any difference, but I'm going to try another restart now (although I think those environment variables will be automatically reset anyway). Next edit: Yes, they were; in fact the variable
XDG_DATA_HOME is now null again.
Anyway the bottom line seems to be that KDE is using the functionality that
file is using, rather than that which
mimetype is using. If I understand things correctly, this means that it is using magic instead of MIME types. I now suspect that magic is responsible for this whole issue.
file manpage seems to be saying that these are the baseline magic files:
/usr/share/misc/magic.mgc Default compiled list of magic.
/usr/share/misc/magic Directory containing default magic files.
(I have these; /usr/share/misc/magic is a link to the empty folder /usr/share/file/magic and /usr/share/misc/magic.mgc is a link to the file /usr/share/file/magic.mgc -- the latter is a 2.1 MB file full of gobbledygook) and the following text:
The information identifying these files
(i.e. "files [which] have a ``magic number'' stored in a particular place near the beginning of the file")
is read from /etc/magic and the compiled magic file
/usr/share/misc/magic.mgc, or the files in the directory
/usr/share/misc/magic if the compiled file does not exist. In addition,
if $HOME/.magic.mgc or $HOME/.magic exists, it will be used in preference
to the system magic files.
(I have confirmed this with
strace, as suggested here.) Neither $HOME/.magic.mgc nor $HOME/.magic exists on my system; but, since presumably xoj files contain precisely that gobbledygook which causes a file to be magically identified as
application/x-gzip, it would do no good to create them (please correct me if I am wrong).
The solution I'm looking for, then, would be a way to have the MIME-type specification override magic for a given file extension; I thought I had seen something that looked like it might provide a hint as to how that might be accomplished, but I can't find it now. Yet surely such a method exists.