When I double click any .avi file, the file does not open and I get this
message:
---start error message---
Cannot open XYZ.avi
The filename "XYZ.avi" indicates that this file is of type "avi
document". The contents of the file indicate that the file is of type
"AVI video". If you open this file, the file might present a security
risk to your system.

Do not open the file unless you created the file yourself, or received
the file from a trusted source. To open the file, rename the file to the
correct extension for "AVI video", then open the file normally.
Alternatively, use the Open With menu to choose a specific application
for the file.
---end error message---

I am using Gnome. I think this is the correct package to file the bug
against, but I could be wrong.


chris.

Same for me (Debian Sid), and it's the second time in some week.

The first time i cannot remember precisely how i've resolved.
Today i have solved doing this:
1) rm ~/.local/share/mime/mime.cache
2) update-mime-database ~/.local/share/mime/
3) logout
But i think 2) is unnecessary.

Unsure if the shared-mime-info package is responsible for this: i've
found this bug while i was googling around for a solution.
Maintainer: feel free to reassign the bug to something more appropriate.

Don't know why this cache become corrupted. I suspect that after the big
gnome updates happened post lenny release, some changes would have been
requested an X restart...

Regards.

Cesare.

    Hello.
    Any news about this?
    This is a blocker for the new Nautilus, while the new Nautilus
doesn't enter Testing, Testing will remain without automounting services.
    There is some problem with the local mime database of the user (look
at the other reports merged with this one), who is responsible for
keeping that file up-to-date?
    Thanks!!!

Correct link for 0.30-2 log is
http://piuparts.debian.org/squeeze/bugged/shared-mime-info_0.30-2.log.

Problematic files (from the bottom of that log):

0m27.4s ERROR: FAIL: Package purging left files on system:
  /usr/share/mime	 owned by: shared-mime-info
  /usr/share/mime/x-epoc	 not owned
  /usr/share/mime/x-epoc/x-sisx-app.xml	 not owned

I have that file on my system (attached), and it has a comment saying:
"Created automatically by update-mime-database. DO NOT EDIT!".

/usr/bin/update-mime-database is part of the shared-mime-info package.

  Regards //Johan

reassign 517768 libglib2.0-0 2.20.0-2
thanks

Hi,

given that this bug actually lies in the code in glib2.0, I’m
reassigning it. The code is duplicated in several source packages, but
the glib copy is the most important one since it leads to nautilus not
recognizing MIME types at all.

This will incidentally allow shared-mime-info to migrate, which will let
testing users have the pleasure to enjoy this bug as well, since the
faulty glib/gnome-vfs code has already migrated.

I still consider this bug RC for squeeze, but this will allow to finish
the gnome-desktop transition without dealing with it.

Cheers,

Hello!

I've tried to understand the problem in the bug report at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517768

I don't know where to start, if someone could suggest a suitable
testcase that would be great!

So far I've found out that the error message originally quoted
in the bug report is no longer part of nautilus (it was dropped
in the gnomevfs->gio switch a long time ago).

I've also installed Lenny + gnome-desktop-environment, played
around a bit with an avi test video, upgraded to squeeze.
This did not result in any problems opening the file.

I wonder if this problem might have only been a concern for
testing->testing upgrades back in 2009....

Le mercredi 15 septembre 2010 à 16:32 +0200, Andreas Henriksson a
écrit :

Thanks for your interest.

Nope, the code is still here in nautilus.

You don’t just need to play around a bit with a video, you need to do
something that creates a ~/.local/share/mime/mime.cache file. This
involves e.g. creating a new MIME type.

It was a problem with lenny→squeeze upgrades back in 2009, but it might
simply have been fixed upstream.

Cheers,

:)

Feel free to point out where... I can't find it.

Thanks for this hint. Here's what I've found:

I started with a clean Lenny install + gnome-desktop-environment pulled in.
I then registered a custom mime type on my user as described in
http://library.gnome.org/admin/system-admin-guide/stable/mimetypes-modifying.html.en
(See attached file, which I put in ~/.local/share/mime/packages/ and then
ran "update-mime-database ~/.local/share/mime/" to generate the mime.cache.)
I verified with gnomevfs-info ~/Desktop/foo.abc that my test file
was actually detected as the new mime type text/x-abc.
I upgraded to squeeze...
After the complete upgrade gnomevfs-info now told me my file was of type
application/octet-stream rather then my custom type.
Double-clicking my test video file opened the movie player without problems,
no error message about mime mismatches or anything.

To get my custom mime type back I had to manually invoke
"update-mime-database ~/.local/share/mime/" and then
foo.abc was again detected as text/x-abc by gnomevfs-info.

It seems the mime cache is now simply ignored if it's in the old
format.

Semi-fixed it seems. I wonder where this leaves us now...

For reference, here's two tarballs with ~/.local/share/mime
before and after I ran update-mime-cache in Squeeze (with my
custom mime type text/x-abc registered for *.abc files).

mime-cache.tar.gz = generated by lennys update-mime-database.
updated-mime-cache.tar.gz = the above + squeezes "update-mime-database ~/.local/share/mime/".

Le jeudi 16 septembre 2010 à 10:47 +0200, Andreas Henriksson a écrit :

Sorry, I meant it is in glib now.

Thanks a lot for the thorough testing.

Well now glib is behaving as it is supposed to do: the old cache format
is simply ignored - instead of breaking the whole MIME subsystem.
However it will not be regenerated upon upgrade. This should be done by
an upgrade script (which are usually run from gnome-settings-daemon),
not by glib itself.

All in all I don’t think we should consider this as RC anymore.

Cheers,

severity 517768 important
thanks

On Thu, Sep 16, 2010 at 12:06:28PM +0200, Josselin Mouette wrote:
[snip]

I agree, lowering severity and hoping someone is interested
in implementing the hook for running update-mime-database for the user.