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:
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.