GNOME Bugzilla – Bug 42126
Username/passworded ftp sites aren't handled properly
Last modified: 2004-12-22 21:47:04 UTC
When I log into ultra5.ionet.net with gftp, it sends me to /home/usersa/linuxfan. When I type this into the location bar in Nautilus, ftp://linuxfan:password@ultra5.ionet.net it sends me to the / folder of ultra5.ionet.net. If I try to manually navigate to the correct folder, it seems to hang. If more information is needed, ask me on IRC. (carbamide) ------- Additional Comments From mathieu@gnome.org 2000-09-19 15:37:53 ---- This bug is completely unrelated to the ftp module as far as I can tell. What happens is that when you ask gnome-vfs to open ftp://linuxfan:password@ultra5.ionet.net, it will internally parse this uri to a GnomeVFSURI. - the uri parser believes that ftp://linuxfan:password@ultra5.ionet.net == ftp://linuxfan:password@ultra5.ionet.net/ - the uri code normalizes the URI after it is parsed so that ftp://linuxfan:password@ultra5.ionet.net is transformed to ftp://linuxfan:password@ultra5.ionet.net. (see the "." at the end ?) - nautilus' NautilusDirectory normalizes uris so that it can actually cache efficiently. As a consequence, it normalizes URIs too which make it unabl to distinguish between ftp://linuxfan:password@ultra5.ionet.net and ftp://linuxfan:password@ultra5.ionet.net/ The consequence is that even if you can fix gnome-vfs, you have to fix nautilus... fun, eh ? ------- Additional Comments From mathieu@gnome.org 2000-09-20 11:22:19 ---- all this issue seem to be really overwhelmingly complez to me. I think the main reason is that both nautilus and gnome-vfs parse uris and do theri own stuff with it. As I see it, there are 2 solutions: - make nautilus not do any parsing and make it rely on gnome-vfs URI parsing code. This sould mean make nautilus not use char * anymore but GnomeVFSURIs. - fix the gnome-vfs part of this problem: ie: make it be to recognize foo from foo/ for all methods. Then, make nautilus do its own uri parsing which is smarter. ie: it recognizes the uri method and then makes foo/ not necessarily different from foo. I prefer solution 1 since it makes the pb much more clear and much more localized. Only GnomeVFSURIs need to used everywhere and if you use gnome_vfs_uri_is_equal, you can forget about all these issues in nautilus. So, the plan of action is: make gnome-vfs parser differentiate foo from foo/ in all cases. make gnome_vfs_canonicalize be really smart: ie: differentiate foo from foo/ only for certain methods. and handle .././ chas in the uri. make nautilus use only GnomeVFSURIs instead of char *uri Now, as far as the foo foo/ smartness, here is the proposed handling: - methods which are non-local should differentiate foo from foo/ (except for eazel service uris since we control those) - methods which are local should not differentiate foo from foo/ here is my current list of methods we should make unable to differentiate: file:// search:// pipe:// Right now, I cannot think of any other method and I know nothing about the services methods. ------- Additional Comments From mathieu@gnome.org 2000-09-20 11:31:03 ---- my new list: ghelp:// help:// man:// info:// hardware:// eazel-time:// eazel-install:// eazel-inventory:// eazel-login:// eazel-sample:// eazel:// more generally: eazel*:// ------- Additional Comments From mathieu@gnome.org 2000-09-20 11:31:23 ---- oops. forgot eazel-services:// ------- Additional Comments From mathieu@gnome.org 2000-09-20 11:50:47 ---- ok, so solution 1 is kept: ie: gnome-vfs has to be stupid (not believe that method://foo/ == method://foo) and nautilus intelligent (be able to recognize between different methods and make them behave differently regarding the trailing / for root.) The policy will be: any non-local method or method we know nothing about, nautilus has to be conservative. ------- Additional Comments From mathieu@gnome.org 2000-09-21 02:01:42 ---- increasing the amount of time: it reflects the time I spent on it and the time left to it which is about 5/6 hours of work. Man, this bug is _evil_ ------- Additional Comments From darin@bentspoon.com 2000-09-28 15:13:39 ---- We still don't even have a design for fixing this. Do we really need it for PR2? The 1-day estimate is incredibly optimistic. ------- Additional Comments From bud@eazel.com 2000-09-29 17:01:34 ---- Seems to only affect ftp with password. Anon ftp not affected. Moving to after post 1.0 ------- Additional Comments From eli@eazel.com 2000-10-16 19:35:50 ---- Batch-assigning QA ownership of remaining bugs to eli@eazel.com ------- Additional Comments From don@eazel.com 2000-12-18 19:46:51 ---- I'm not confident of this time estimate without a design here. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:36 ------- The original reporter (linuxfan@ionet.net) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org.
mark fixed, works on both my schools ftp sites.
Louie: I think this has been fixed. It works with both of my schools ftp servers. Can you please try, and if it works marked fixed, or otherwise mark future.
Looks fixed here, though there are other ftp bugs that ought to be fixed. Mathieu: please reopen if you are still seeing this.
Now nautilus doesn't let you move up the directory tree using the up arrow to the / directory. see bug 74711.