[Nautilus-list] Re: Future versions of gnome-vfs sharing MIME database with file(1)

[monkeyiq <monkeyiq users sourceforge net>]

Darin Adler <darin bentspoon com> writes:

> on 10/7/01 12:19 PM, monkeyiq at monkeyiq users sourceforge net wrote:
> 
> > I don't know which file(1) you are using, but,
> > 
> > $ file -i /usr/bin/file
> > /usr/bin/file: application/x-executable, dynamically linked (uses shared
> > libs), not stripped
> > 
> > the file I use has mime included, and I have made it into a shared library
> > libfile.so and modified the client to use it a while back. I'm still in
> > the process of merging my changes into the main tree.
> 
> I didn't realize that file(1) has two separate magic files, one for MIME and
> one for non-MIME.

-rw-r--r--    1 root     root       226061 Jun  9 21:29 /usr/share/magic
-rw-r--r--    1 root     root        19688 Jun  9 21:29 /usr/share/magic.mime

I suspect that maybe the nautilus mime db has more entries.

The file I am using IIRC is the standard one thats on RedHat distros,
though the shared lib part is still only on witme.sf and my boxen. I
keep pestering the maintainer about it every now and again, but he
is very busy :(

File 3.33 is available from Simtelnet and its mirrors:
ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2apps/file333b.zip

Mine is based on 3.35, its available from witme's sf.net page.

> 
> We might want to merge the magic number database used by gnome-vfs with
> what's used by file(1). While invoking the file tool each time is
> impractical, we might be able to start using libfile.so in a future version
> of gnome-vfs. Does libfile.so have a streaming interface, or does it require
> a filesystem file? 

That is the only limitation at this point, it needs a file. I will probably 
fix this soon because streaming data through a fifo in ferris that is not
already a filesystem file is a PITA. I originally didn't hack this straight
in to try to keep the patch smallish. though its been soo long now trying to
merge the patch I might just do a little more hacking on libfile.so and let
the chips fall where they may. Though there is also the temptation to create
a complete rewrite using a few modern ideas like SIMD for filetype sniffing.
Though even if I do this I can keep the same API as libfile.so already uses 
:)

> The gnome-vfs MIME sniffing code has a nicely flexible
> interface (found in gnome-vfs-sniff-buffer.h) based on passed-in seek and
> read functions, and it has special code to recognize text, mp3, and gzip
> files better than you can do with a magic file entry.

I'll take a look.

> 
> At the moment, the gnome-vfs MIME magic table has a lot of entries for
> common types that aren't in the file(1) MIME magic table, but we can fix
> that too.
> 

The main reason I hacked file(1) was so that I could merge my stuff into
the main distro and then avoid yet another dependancy, which seems to be
more important to many Unix geeks than the code sharing that was also
happening:)

This would also be quite handy because the output would be identical for
nautilus, file(1), and ferris based applications (ferrisls, witme3)
for file/mime sniffing.

 
----------------------------------------------------
Click here to find out if your browser sucks or not.
http://witme.sourceforge.net/libferris.web/