Bug 527877
Summary: | shared-mime-info 0.70 breaks GNOME applications | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michel Lind <michel> |
Component: | shared-mime-info | Assignee: | Bastien Nocera <bnocera> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | rawhide | CC: | alexl, axet, bnocera, leigh123linux, mclasen, tue |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-10-12 01:35:20 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Michel Lind
2009-10-08 03:12:56 UTC
Does update-mime-database ~/.local/share/mime make things work again ? Alex, I guess this is a side effect of the lame caching logic in xdgmime which we discussed yesterday ? With the latest 0.70 package installed I loose all the pretty folder icons , they become plain white. (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 ) 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 (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 Can you try: strace -o log gvfs-info -a "standard::content-type" /etc/issue grep mime.cache log (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 ~]$ (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 ~]$ 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. running update-mime-database ~/.local/share/mime certainly fixed the problem on my system. (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 ~]$ do people for whom it is still not working have glib2 2.22.2 installed ? (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 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. Turns out this did not work with gnome-vfs apps like gthumb, so also ensure you get: gnome-vfs2-2.24.2-1.fc12 tagging has been requested for gnome-vfs2-2.24.2-1.fc12 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! Thanks Alex for the updated gnome-vfs. |