After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 150585 - FileChooser cannot handle an remote mount with unreadable parent
FileChooser cannot handle an remote mount with unreadable parent
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
: 163453 (view as bug list)
Depends on: 561998
Blocks:
 
 
Reported: 2004-08-19 20:59 UTC by William Jon McCann
Modified: 2018-02-10 03:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description William Jon McCann 2004-08-19 20:59:42 UTC
It seems that the FileChooser cannot display an ftp:// directory with an
unreadable parent.

It is common to configure ftp sites to have a parent directory unreadable but
executable.  It should be possible to pass through this directory if the name of
the subdirectory is known.

Should be able to navigate to the unreadable directory and then use CTRL-L to
type in the name of the subdirectory.  The file-chooser is able to do this on
local filesystems.
Comment 1 Federico Mena Quintero 2005-04-28 19:56:15 UTC
This is a duplicate.  Please try this again with the latest in the 2.6 series or
HEAD; feel free to reopen the bug if the problem persists.

(Please make sure you update both your gtk+ and libgnomeui).

*** This bug has been marked as a duplicate of 162617 ***
Comment 2 William Jon McCann 2005-04-28 20:58:42 UTC
Unfortunately, it still doesn't work with latest gtk-2-6 and HEAD libgnomeui.

Here is a test case:

Unreadable contents:
ftp://acs.pha.jhu.edu/pub/users/

Should be readable:
ftp://acs.pha.jhu.edu/pub/users/testing-only/
ftp://acs.pha.jhu.edu/pub/users/testing-only/bar
Comment 3 Federico Mena Quintero 2005-04-28 22:57:27 UTC
Thanks for the links; I'll test this soon.
Comment 4 Federico Mena Quintero 2005-05-05 18:00:48 UTC
Changing the product/component as this is in libgnomeui/file-chooser rather than
GTK+.
Comment 5 Sebastien Bacher 2005-07-23 12:17:29 UTC
The Ubuntu bugzilla has a similar bug:
http://bugzilla.ubuntu.com/show_bug.cgi?id=11754. This is an issue for webdav
and NFS too according to the submitter.
Comment 6 Sebastien Bacher 2005-07-23 12:24:14 UTC
*** Bug 163453 has been marked as a duplicate of this bug. ***
Comment 7 Sebastien Bacher 2005-07-23 12:25:17 UTC
The duplicate has a webdav configuration do get the issue too.
Comment 8 Kjartan Maraas 2008-08-28 10:27:11 UTC
Moving this to gvfs.
Comment 9 Michel Belleau 2008-10-08 16:01:57 UTC
I do get the same bug in Ubuntu Hardy Heron (8.04), any developpements on this issue ?

I want to create a shortcut in Places to davs://my.own.server/mbelleau/.
I have full access to /mbelleau/, but not to /.

I have no problem connecting to the dav(s) share using mount or cadaver.

The server is lighttpd with the webdav module enabled.
Comment 10 Christian Kellner 2009-10-30 10:28:44 UTC
I am pretty sure that the gvfs webdav backend should be able to handle this situation, since the webdav backend will set /mbellau as the mount_prefix and therefore as the remote share root.

The general problem therefore, I guess, is that if the filesystem root is not accessible but the "home directory" of the remote share is. The file-chooser should use the g_mount_get_default_location () once the patch from 561998 is committed, so clicking on the Mount will display the accessible home directory of the network share and not trying to access /. When doing that the general problem should be solved.

There is of course the problem of bug 560357 which currently would cause the FTP to fail even if 561998 was fixed. I am not sure what to do, but my best take on that is to rename this bug to address the general problem.
Comment 11 Matthias Clasen 2018-02-10 03:22:58 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.