1

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: xoj properties from 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
application/x-xoj=xournal.desktop;
to ~/.local/share/applications/mimeapps.list

3) added the MIME type application/x-xoj in the File Associations System Setting
(with appropriate content):
file-associations-xoj
(Note also that application/x-gzip specifies only the .gz extension:
enter image description here.)

4) copied xournal.xml to /usr/share/mime/application
as suggested here

5) 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/application/x-xoj.xml,
~/.local/share/mime/packages/application-x-xoj.xml, and
~/.local/share/mime/types which contains only the text application/x-xoj.
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_HOME and $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

XDG_DATA_HOME=$HOME/.local/share  

and

XDG_DATA_DIRS=/usr/local/share/:/usr/share/  

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.

New edit

So the 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.

3
  • Have you tried opening a context menu on a xoj file in Dolphin and selecting "Open with..." then checking "Remember application association..."?
    – warvariuc
    Feb 23, 2014 at 9:06
  • Yes. It doesn't work. (The 'updating system configuration' window appears and then the file opens with Xournal; but after I close it everything is the same: I click the file and it opens with Ark.)
    – Archelon
    Feb 23, 2014 at 9:11
  • I cannot help you, but I would suggest asking on KDE forum, as there are much more chances to find the answer
    – warvariuc
    Feb 24, 2014 at 5:28

1 Answer 1

1

Not an answer, but just a comment:

tried cat $XDG_DATA_HOME, which set the value (to nothing) instead of reporting it

cat will certainly not set the value of the variable. cat would print the contents of the file of the name you provide it with, or in the absence of a file name it would print what it reads from standard input. Furthermore the variables are expanded by the shell you are running (usually /bin/bash) and thus cat doesn't even ever see the name of the variable.

Now in your specific situation, the variable seemingly wasn't set, thus expanded to nothing, thus cat had no parameter, thus cat printed from stdin and I presume you had to Ctrl-C-end it, or maybe Ctrl-D (end of file).

2
  • "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" Maybe you could try analysing what files the ppa version installs and how it makes it work correctly?
    – krusty
    Feb 24, 2014 at 6:29
  • "I presume you had to Ctrl-C-end it": Yes. "try analysing what files the ppa version installs and how it makes it work correctly": I imagine I will end up trying to do just that.
    – Archelon
    Feb 24, 2014 at 6:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .