If it's bad magic, update your distro. If it's a Konqueror error, file a bug. I'd be surprised if upstream hasn't addressed this (quick DDG/Google doesn't turn up any similar complaints).
But they are zip files. (Though `file somebook.epub tells me "data". Sigh. Desktop and OS seem to be on different pages.)
Just like .css and .log are text files, but I may not want the same default file handler.
What I like is having *.epub open in, say, calibre, but if I append a .zip extension then it will open in xarchive.
Anyways, I open most things from the command line and wrote my version of 'open' so I get what i expect 99% of the time. :)
I'm using KDE3 so I'm not expecting any upstream fixes for this in my lifetime. I can live with crafting my own solutions.
What might work best is if mime types were used by default but forcing behavior for specific extensions was much easier. Get the best of both worlds (which I can mostly do in KDE3 Konqueror but it's tedious.)
File(1) on my Debian wheezy says they're epubs. File has dealt with nested formats for decades. It examines up to the first 1024 bytes of the file IIRC.
Other examples: tar.gz, WAR files, most ODF formats.
Or do you mean storing a database of the application associated, specifically, with any given file (so that I might open, say, a given myprog.c with vi, emacs, or textmate)?
The Mac OS resource fork model attempts the second, but it's an inherently single-user concept that leaves artifacts around for other users and/or on shared media in an annoying way. A shadow filesystem maintained on a per-user basis under their control would be a preferred solution.
Files used to be tied to applications directly. While I prefer the BeOS approach of MIME-type, it's not nearly as user-friendly as a file extension.
OS X tries to hide extensions by default, which like the behavior in Windows that's similar, seems dangerous. Too many times people have been stung by sexy.jpg.exe.
