> I guess this is really a posting to cK but I thought I would post it to
> the list since others mind have some info on how to do it and where to
> get the info from.
> First of all if I want to read up on the file magic.txt that is used by
> EFSD and similar files used by other file-magic programs, does anyone
> have any good URLS?
* that file is not actually used anymore. That information is stored in
an XML file now, which is much more standardized, plus it's only a
fraction of the size of the old db file, plus parsing is heaps faster.
* the syntax of magic.txt is a royal pain in the ass. It's the same as
in the file that the file(1) command uses, if you still want to read up
on that, man 7 magic helps somewhat.
There will be GUI tools for editing those entries in the near future,
but I'm busy with other things right now.
> Next is this: while I know that the .db file format is a binary one I
> was wondering if file magic could be added to spot when a *.db file was
> an E17 background/icon/cursor.etc
In theory we could add a magic value somewhere by hacking edb. Another
way that's more expensive to look up but simpler to add would be to just
define a policy that our dbs need to have keys like
"/metainfo/contenttype" or something that lets us query the type of db.
In the worst case, we could just use .tdb for a theme db, .cdb for a
cursor db, .bdb for a background db.
> All of this files first off all match the file magic of the db stuff,
> but while they are binary files they also have strings that can be
> matched. Ie;
> a background .db file always has the string "/type/bg"
> cursors seem to always have the string "/cursor/image"
> and icons always have the string "/icon/normal"
> each of these string values are atcally the names of an important key
> names that seem to always be present in files of that type, and that I
> don't think would be present in any files not of that type (well not in
> other db files anyhow)
> So usig that infomation shorly some file magic can be added into efsd's
> magic data for them, can't it?
Yes, basically. Unless we modify the way Edb stores the db, those tests
would be more work (and thus slower) than ordinary ones (which just jump
to some offset in the file and look for byte patterns). In the above
case with /metainfo/contenttype, Efsd would need to open the file and do
an actual btree query, which is really slow.
There's other cases whith the same problem -- for example in a gzipped
postscript mypaper.ps.gz. The extension suggests it's a gzip'd
postscript, but all that file magic can tell me is that it's a gzip
file. Checking if the contained file is actually a postscript file is
certainly going to be *really* expensive.
I could setup test chains in Efsd somewhat like this:
1) test for file magic --> aha, it's a gzip file
2) test for file extension --> ah, could be a gzipped postscript
but that's not 100% reliable anymore. I'm not sure how to handle this