Most ubuntu apps fail to open network files

[Liken Otsoa]

Binary package hint: nautilus

I think this is an important ubuntu general bug, and it does the system pretty unusable with networks.

Most Ubuntu applications fails to open network sftp:// smb:// files with nautilus.

HTML files: Firefox FAILS, Opera FAILS,..
PDF files: Evince OK, Acroread FAILS, KPDF FAILS, XPDF FAILS
Image files: Gnome Eye OK, GQVIEW FAILS
openoffice: FAILS sometimes

And this is the iceberg's tip, there is a lot more apps and file tipes failing.

Is there not a transparent protocol for apps open network files??

Thx.

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it, because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" [WWW] http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem.

We have instructions on debugging some types of problems at [WWW] http://wiki.ubuntu.com/DebuggingProcedures

At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).
Thanks!

[Liken Otsoa (liken)]

I thought it was very easy to reproduce:

1. Just open with nautilus a network directory. A samba directory smb:// or a SSH directory sftp://
2. Click on a file

if HTML file, behaviour expected: Firefox opens it. Actually encountered: Firefox doesn't understand protocol.
if PDF file, behaviour expected: Default PDF reader opens it. Actually: KPDF freezes, Acroread Blank, XPDF Fails.

The problem is that most applications does not understand how to open files with smb or sftp protocol in their path. They only understand how to open local files or URLs if browsers, I think file managers would give them mounted network local paths (Without smb:// or sftp:// ).

Thx.

[Liken Otsoa (liken)]

is it complete now?

[mohan43u (mohan43u)]

Also Applications can't able to open bluetooth files(obex://)

[A. Walton (awalton)]

Please attach bugs to applications that don't work under GIO, that haven't already been ported, not Nautilus. Many applications have been ported (http://live.gnome.org/GioPort/) but it is simply impossible to port every application in the entire platform in a single release. For GNOME applications that advertise that they take URIs in their .desktop files (with %u), they should not if they cannot accept URIs from GVFS mounts (though many still do as they expect the VFS to be GnomeVFS). There's a fix that may be committed in GIO that will allow some fallback ability if you have the GVFS-Fuse module installed and are a member of the Fuse group, but I believe that's still being decided on for Ubuntu (Sebastian would know more about it than I would, I'm afraid. See GNOME bug 528670 for the idea).

As for KDE applications, unless (or until) a KIO-GIO bridge is completed, there's not a whole lot we can do; our VFSes are otherwise incompatible, and applications on both sides are validly advertising that they support URIs which they clearly can't in such a cross-desktop fashion. This needs discussion on the FreeDesktop.org list, with agreements on the semantics for URI schemes we share and/or keys that we can add to application's .desktop files to specify which VFS we're expecting, so that applications can properly deal with invalid URIs (e.g. fish:/ being passed to GEdit or gphoto2:// being passed to Krita).

This, however, should probably be closed as not a bug; misbehaving applications are clearly outside of Nautilus' jurisdiction.

[Sebastien Bacher (seb128)]

right, that's not a nautilus bug, we will try to get the automatic fuse use thing though

[nf2 (mail2nob)]

A KIO-GIO Bridge for KDE4 applications already exists:

http://live.gnome.org/KioGioBridge