Bug 527877 - shared-mime-info 0.70 breaks GNOME applications
shared-mime-info 0.70 breaks GNOME applications
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: shared-mime-info (Show other bugs)
rawhide
All Linux
high Severity high
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-07 23:12 EDT by Michel Alexandre Salim
Modified: 2009-10-25 16:09 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-11 21:35:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Michel Alexandre Salim 2009-10-07 23:12:56 EDT
Description of problem:
With the latest 0.70 package, Nautilus can no longer display desktop application launchers; likewise, gthumb reports a directory full of JPEGs as being empty.

Reverting to 0.60-5 fixes the problem.

Version-Release number of selected component (if applicable):
shared-mime-info-0.70-1.fc12

How reproducible:
Always

Steps to Reproduce:
1. Update to shared-mime-info 0.70
2. Log in to the GNOME desktop
3. Create a desktop launcher, if necessary
4. Run gthumb on a directory containing images
  
Actual results:
Desktop launcher misidentified as executable text file
gThumb does not recognize any image

Expected results:
Both should work

Additional info:
Comment 1 Matthias Clasen 2009-10-08 01:37:19 EDT
Does 

update-mime-database ~/.local/share/mime

make things work again ?
Comment 2 Matthias Clasen 2009-10-08 01:38:51 EDT
Alex, I guess this is a side effect of the lame caching logic in xdgmime which we discussed yesterday ?
Comment 3 leigh scott 2009-10-08 05:19:36 EDT
With the latest 0.70 package installed I loose all the pretty folder icons , they become plain white.
Comment 4 leigh scott 2009-10-08 05:23:09 EDT
(In reply to comment #1)
> Does 
> 
> update-mime-database ~/.local/share/mime
> 
> make things work again ?  


No it doesn't, the problem is system wide. ( rpm's in /var/html/www have also lost there icon )
Comment 5 Michal Schmidt 2009-10-08 05:26:37 EDT
Other funny effects are:
 - evince is unable to open any PDF ("Filetype unknown (application/octet-stream) is not supported").
 - text from thumbnails of *.txt files on the desktop which normally appear on the icons now overflow the icons by a big margin
Comment 6 leigh scott 2009-10-08 05:27:41 EDT
(In reply to comment #4)
> (In reply to comment #1)
> > Does 
> > 
> > update-mime-database ~/.local/share/mime
> > 
> > make things work again ?  
> 
> 
> No it doesn't, the problem is system wide. ( rpm's in /var/html/www have also
> lost there icon )  

Heres a link to a picture of the problem.

http://forums.fedoraforum.org/showthread.php?t=231565
Comment 7 Alexander Larsson 2009-10-08 06:28:35 EDT
Can you try:

strace -o log gvfs-info -a "standard::content-type" /etc/issue
grep mime.cache log
Comment 8 leigh scott 2009-10-08 07:23:06 EDT
(In reply to comment #7)
> Can you try:
> 
> strace -o log gvfs-info -a "standard::content-type" /etc/issue
> grep mime.cache log  


[leigh@localhost Thu Oct 08 12:18:29 ~]$ strace -o log gvfs-info -a "standard::content-type" /etc/issue
attributes:
  standard::content-type: text/plain
[leigh@localhost Thu Oct 08 12:18:32 ~]$
Comment 9 leigh scott 2009-10-08 07:26:26 EDT
(In reply to comment #8)
> (In reply to comment #7)
> > Can you try:
> > 
> > strace -o log gvfs-info -a "standard::content-type" /etc/issue
> > grep mime.cache log  
> 
> 
> [leigh@localhost Thu Oct 08 12:18:29 ~]$ strace -o log gvfs-info -a
> "standard::content-type" /etc/issue
> attributes:
>   standard::content-type: text/plain
> [leigh@localhost Thu Oct 08 12:18:32 ~]$  


Sorry hit commit to soon.


[leigh@localhost Thu Oct 08 12:25:38 ~]$ grep mime.cache log
stat("/home/leigh/.local/share//mime/mime.cache", {st_mode=S_IFREG|0664, st_size=980, ...}) = 0
stat("/home/leigh/.local/share//mime/mime.cache", {st_mode=S_IFREG|0664, st_size=980, ...}) = 0
open("/home/leigh/.local/share//mime/mime.cache", O_RDONLY) = 4
stat("/usr/local/share//mime/mime.cache", 0x7fff455bf810) = -1 ENOENT (No such file or directory)
stat("/usr/share//mime/mime.cache", {st_mode=S_IFREG|0644, st_size=107424, ...}) = 0
open("/usr/share//mime/mime.cache", O_RDONLY) = 4
[leigh@localhost Thu Oct 08 12:25:47 ~]$
Comment 10 Alexander Larsson 2009-10-08 08:17:13 EDT
Hmm, the %post for s-m-i 0.7 would have updated /usr/share/mime/mime.cache, and assuming you ran "update-mime-database ~/.local/share/mime" as per comment #1 both these should be version 1.2 format and we don't read any other mime.cache files, so we should fallback to the non-cached files. Weird.
Comment 11 Matthias Clasen 2009-10-08 08:43:36 EDT
running update-mime-database ~/.local/share/mime certainly fixed the problem on my system.
Comment 12 leigh scott 2009-10-08 08:52:21 EDT
(In reply to comment #10)
> Hmm, the %post for s-m-i 0.7 would have updated /usr/share/mime/mime.cache, and
> assuming you ran "update-mime-database ~/.local/share/mime" as per comment #1
> both these should be version 1.2 format and we don't read any other mime.cache
> files, so we should fallback to the non-cached files. Weird.  


The icons are back to normal after rerunning "update-mime-database ~/.local/share/mime" several times and restarting nautilus.


Here's the output (now it's working)


[leigh@localhost Thu Oct 08 13:45:08 ~]$ update-mime-database ~/.local/share/mime
[leigh@localhost Thu Oct 08 13:45:38 ~]$ strace -o log gvfs-info -a "standard::content-type" /etc/issue
attributes:
  standard::content-type: text/plain
[leigh@localhost Thu Oct 08 13:46:34 ~]$ grep mime.cache log
stat("/home/leigh/.local/share//mime/mime.cache", {st_mode=S_IFREG|0664, st_size=980, ...}) = 0
stat("/home/leigh/.local/share//mime/mime.cache", {st_mode=S_IFREG|0664, st_size=980, ...}) = 0
open("/home/leigh/.local/share//mime/mime.cache", O_RDONLY) = 4
stat("/usr/local/share//mime/mime.cache", 0x7fff4eaf5970) = -1 ENOENT (No such file or directory)
stat("/usr/share//mime/mime.cache", {st_mode=S_IFREG|0644, st_size=107424, ...}) = 0
open("/usr/share//mime/mime.cache", O_RDONLY) = 4
[leigh@localhost Thu Oct 08 13:46:38 ~]$
Comment 13 Matthias Clasen 2009-10-08 09:04:07 EDT
do people for whom it is still not working have glib2 2.22.2 installed ?
Comment 14 leigh scott 2009-10-08 09:19:45 EDT
(In reply to comment #13)
> do people for whom it is still not working have glib2 2.22.2 installed ? 

[leigh@localhost Thu Oct 08 13:46:38 ~]$ rpm -q glib2
glib2-2.22.1-1.fc12.x86_64
glib2-2.22.1-1.fc12.i686
Comment 15 Alexander Larsson 2009-10-08 09:26:00 EDT
So, does anyone have this problem with:
* s-m-i 0.70
* glib2 2.22.2
* restarted nautilus

If so that is bad and I need to debug this.
Comment 16 Alexander Larsson 2009-10-08 11:17:29 EDT
Turns out this did not work with gnome-vfs apps like gthumb, so also ensure you get:
 gnome-vfs2-2.24.2-1.fc12
Comment 17 Matthias Clasen 2009-10-08 12:03:48 EDT
tagging has been requested for gnome-vfs2-2.24.2-1.fc12
Comment 18 Michel Alexandre Salim 2009-10-10 20:56:58 EDT
With the latest gnome-vfs2, and shared-mime-info 0.70-3, I didn't even have to do the update-mime-database invocation -- things continue to work, no icon is missing. Thanks!
Comment 19 Bastien Nocera 2009-10-11 21:35:20 EDT
Thanks Alex for the updated gnome-vfs.

Note You need to log in before you can comment on or make changes to this bug.