Opening files in Nautilus with the default application usually works perfectly on my system. Also the applications listed as alternatives in the context menu are as expected. What I observed is that the problem is related to the URI with which the file is tried to be opened. When using a "normal" file location (e.g. "/mnt/some/dir/a.pdf") nautilus opens the file correctly with Adobe Reader. When using a URI with a different protocol (e.g. "smb://host/some/dir/a.pdf") the default is suddenly GIMP instead of Adobe Reader. The context menu does not even list Adobe Reader as alternative. The strange thing is that the properties dialogue for the file lists the correct applications under the "Open with" tab, even the default is correctly Adobe Reader. (I have a network storage which is mounted under "/mnt/", but can also be accessed by nautilus using "smb://..."). I just checked and verified that nautilus produces the same wrong behaviour with "sftp://...". See also bug #242460 with similar probs in epiphany and comments on nautilus. Currently using nautilus-2.30.1-r2. Portage 2.1.9.24 (default/linux/x86/10.0/desktop, gcc-4.3.5, glibc-2.12.1-r3, 2.6.33-gentoo i686) ================================================================= System uname: Linux-2.6.33-gentoo-i686-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4200+-with-gentoo-2.0.1 Timestamp of tree: Fri, 05 Nov 2010 10:00:22 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] ccache version 2.4 [enabled] app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r1 dev-lang/python: 2.6.6-r1, 3.1.2-r4 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1-r1 sys-apps/openrc: 0.6.3::sabayon sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.6.3-r1, 1.7.9-r2, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.3.5, 4.4.1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.82 virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="* -@EULA dlj-1.1 skype-eula AdobeFlash-10.1" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=athlon-xp -D__STDC_CONSTANT_MACROS" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs ccache distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="de_DE.UTF-8" LC_ALL="de_DE.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="de en" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/local /var/lib/layman/arcon /var/lib/layman/x11 /var/lib/layman/gnome2-globalmenu /var/lib/layman/sunrise /var/lib/layman/zugaina /var/lib/layman/gnome /var/lib/layman/sabayon /var/lib/layman/suka /var/lib/layman/calculate /var/lib/layman/belak" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac accessibility acl acpi ads alsa avahi berkdb bluetooth bonobo branding bzip2 cairo cdr chipcard cli consolekit cracklib crypt cups cxx dbus dns dri dts dvd dvdnav dvdr emboss encode exif fam firefox flac foomaticdb fortran ftp gdbm geldkarte gif gimp glitz gnome gnome-keyring gphoto2 gpm gtk gtk2 hal hbci iconv imap ipv6 java jpeg lcms ldap libnotify mad mdnsresponder-compat mikmod mmx mng modules mp3 mp4 mpeg mudflap mysql nautilus ncurses networkmanager nls nptl nptlonly nsplugin nvidia ogg oggvorbis opengl openmp pam pango pcre pdf perl png ppds pppd pulseaudio python qt3support qt4 quotes readline samba samba4 scanner sdl session sockets spell sqlite sse sse2 ssl ssse3 startup-notification svg sysfs tcpd tetex tiff truetype unicode usb v4l v4l2 vdpau vorbis wmf x264 x86 xcb xml xmms xorg xulrunner xv xvid xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" CAMERAS="canon kodak_ez200 ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en" PHP_TARGETS="php5-2" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nouveau nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
can you reproduce this problem with other mime types ?
Please also try on a new created user account and attach ~/.xsession-errors file just after reproducing the problem
Created attachment 254079 [details] e
(In reply to comment #3) > Created an attachment (id=254079) [details] > e > Argh.. somehow managed to hit return before finishing... It's the .xsession-errors of a freshly created test user, directly after logging into a gnome session for the first time and trying to open a pdf via "smb:" protocol in nautilus (which reproduced the problem, Gimp was started instead of acroread...).
(In reply to comment #1) > can you reproduce this problem with other mime types ? > It does not happen with jpg (gimp), svg (gthumb), odb (open office). For those I see the same behaviour for accessing via "file:" and "smb:" protocol specifiers. However, I figured out some more: When selecting "Document Viewer" (Evince) in the Nautilus properties dialogue->open-with tab for pdf files, Evince is used in both cases. So with Evince everything seems to work ok. After changing back to the "Adobe Reader" entry, Nautilus opens pdf files as expected with Adobe Reader using "file:", but now keeps on using Evince when using "smb:" protocol! Interesting, isn't it? Think I understand now: Looks like it is acroread which is unable to open via "smb:", and Nautilus silently falls back to Evince (last one in a history of previously used applications or so?) If this is the case, I think it is not really a bug in Nautilus. It's rather a bit irritating behaviour to auto-fallback without message hinting that something went wrong. So maybe that could be improved.
Maybe you could try to open that smb file passing the path directly to "acroread" command. You could also try the same with "gvfs-open" instead of "acroread" to see if some message is shown when the file is opened using evince instead of (expected) acroread
(In reply to comment #6) > Maybe you could try to open that smb file passing the path directly to > "acroread" command. You could also try the same with "gvfs-open" instead of > "acroread" to see if some message is shown when the file is opened using evince > instead of (expected) acroread > Tried passing the smb path to acroread.. it simply does nothing if an instance of acroread is already running, or opens but with no document. There's no error message pointing out that the path could not be opened or is not supported. BTW: xpdf shows the same problem. With smb paths (and probably anything else than a plain path/filename) it responds with "..no such file or directory..". In Nautilus that means on smb-paths it won't open with xpdf, but with the last/some other application Nautilus knows and which is working. After all it is quite logic what's going on, but without thinking about the details the behaviour of Nautilus appears weird and broken. A little dialogue telling the user there was a problem opening file foo with application bar and asking with which application to try again would help a lot.
(In reply to comment #7) > After all it is quite logic what's going on, but without thinking about the > details the behaviour of Nautilus appears weird and broken. A little dialogue > telling the user there was a problem opening file foo with application bar and > asking with which application to try again would help a lot. > If the diagnostic is correct, that should be reported directly to upstream (bugzilla.gnome.org)
I think such a report would be closed wontfix. The problem is simple, the application you selected is not able to handle the URI scheme you want it to open so gvfs-open selects the next best fit. In the end, all that matters is that your file is open right ? I imagine it would also be really complicated to include in the gui a place that shows the kind of message you are proposing. Even if only informative.
(In reply to comment #9) Next best fit... good point. When you want to open a PDF, would you consider it a 'fit' when Gimp is used to display it? I'd like to see that clever piece of code deciding for me how I have to view a file ;-) Why not open everything in a hex editor? After all, the file would be 'open' then... I think it's worth reporting this as an enhancement, be it difficult to do or not.
This is anyway an upstream issue (bugzilla.gnome.org) Best regards
