235931 - gnome vfs smb bad links?

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[basic]

while testing the new gnome-vfs smb stuff. I found that going to smb:/// gives a
list of workgroups that have the wrong links. For example, a workgroup named
"abc" the link will go to "smb:///abc" where it should go to "smb://abc/". This
cause moz to popup a save as dialog saying that the "file" is of type
"application/x-gnome-app-info".

Comment 1

[basic]

another one is when one is in a workgroup like smb://abc/ links to hosts are
wrong as they link to smb://abc/host when it should be smb://host

moz seems to get rather crashy after playing with this protocol. Might be a
gnome vfs smb bug though (my nautilus has the same effect).

Comment 2

[basic]

another thing about the application/x-gnome-app-info thing, when I try to save
it, moz seems to push cpu to 100% and the "this script is is slowing moz down"
popup keeps coming up.

My guess is that some how, we need to handle application/x-gnome-app-info, and
use the information in there to direct to the right path?

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #2)
> My guess is that some how, we need to handle application/x-gnome-app-info, and
> use the information in there to direct to the right path?

I rather think that darin's XXX comment about using GnomeVFSURI needs to be
fixed to handle this correctly...

Comment 4

[Darin Fisher]

thanks for catching these URL handling mistakes.  it's going to take some work
to get them fixed.  the way URLs need to be resolved here definitely makes
things tricky.

maybe we can fudge things by making 

  "smb:///abc" map to "smb://abc/" in our NewURI implementation

as for

  "smb://abc/host" needing to map to "smb://host"

that one is going to be very difficult to fix i think.  there is no way to tell
that "abc" is not the host name :-(

i think the SMB gnome-vfs module might need to be rev'd to map smb://abc/host to
smb://host... unless the gnome-vfs API provides some way for us to determine
this.  hmm...

yes, the SMB module is a bit unstable.  i suggest upgrading your gnome-vfs and
gnome-vfs-extras to the latest versions.

Comment 5

[Darin Fisher]

> there is no way to tell that "abc" is not the host name :-(

or rather... from simple inspection of the URL string, there is no way to tell
that "abc" is not the host name.

parsing application/x-gnome-app-info


> I rather think that darin's XXX comment about using GnomeVFSURI needs to be
> fixed to handle this correctly...

biesi: can you clarify this point?  what GnomeVFSURI method are thinking might help?

Comment 6

[Darin Fisher]

> parsing application/x-gnome-app-info

parsing application/x-gnome-app-info sounds like it could be done to extract the
information needed to distinguish workgroups from hosts.  i'm not sure how we
will use that when we try to load smb://abc/host since we won't know that "abc"
is a workgroup unless we request smb://abc/.  we could try loading smb://abc/ as
a fallback measure if loading smb://abc/host fails, but that's getting pretty
kludgy.

Comment 7

[basic]

(In reply to comment #6)
> parsing application/x-gnome-app-info sounds like it could be done to extract the
> information needed to distinguish workgroups from hosts.  i'm not sure how we
> will use that when we try to load smb://abc/host since we won't know that "abc"
> is a workgroup unless we request smb://abc/.  we could try loading smb://abc/ as
> a fallback measure if loading smb://abc/host fails, but that's getting pretty
> kludgy.

well smb://abc/host is a "desktop entry" file:
http://freedesktop.org/Standards/desktop-entry-spec/0.9.4/

an example of what the file looks like can be found here:
http://freedesktop.org/Standards/desktop-entry-spec/0.9.4/apa.html

here is the file I've got from saving the link:

[Desktop Entry]
Encoding=UTF-8
Name=WORKGROUP
Type=Link
URL=smb://WORKGROUP/
Icon=gnome-fs-network

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #5)
> biesi: can you clarify this point?  what GnomeVFSURI method are thinking might
help?

Oh, hmm. I have to admit I don't know GnomeVFSURI :) and I only skimmed comment
0, to be truthful. it sounded to me like "gnomevfs uris mishandled", which made
me think that using GnomeVFSURI may help.

Comment 9

[basic]

I think the right way to fix this bug is to parse the
application/x-gnome-app-info "desktop entry" and see if they are of Type=Link,
if they are, grab the URL= entry and go there. I don't think we need to handle
the other types.

Comment 10

[Darin Fisher]

yeah, i have a hackish patch for this that sort of works.  the only problem is
that loading smb:// or smb://host causes memory corruption with the version of
libsmb that ships with rh9 and fc1.  i haven't tested the latest vesion of
gnome-vfs-extras to see if they have solved the problem.

Comment 11

[Darin Fisher]

hoping to have time for this by 1.8 beta, but not very likely...

Comment 12

[Darin Fisher]

-> future (i won't have time for this during 1.8)

Comment 13

[basic]

in my gnome-desktop-2 package (on gentoo) there's a header file
libgnome/gnome-desktop-item.h that might help here. Judging from gnome cvs, it
has been there since gnome-2.0 , hasn't changed since 2.2 (2002?).