GNOME Bugzilla – Bug 614401
Incorrect handling of FTP 'pwd' reply
Last modified: 2010-04-08 17:50:19 UTC
When GVFS sends 'pwd' command to FTP server is gets reply in the following format: 257 "/" is current directory. This line is not parsed correctly and everything following the "257" code is taken as a default location resulting in erroneous behavior of Nautilus. Tested in Ubuntu 10.04 AMD64, GVFS version 1.6.0-0ubuntu1. I have attached a proposed patch.
Created attachment 157532 [details] [review] PWD parsing
*** Bug 614445 has been marked as a duplicate of this bug. ***
Hello Dimitry! Thanks for finding and fixing the bug. Looking at your patch I got the impression the problem could be fixed easier then your solution. I'll post a patch soon. Would be nice to get your comments on what you think about the alternative solution.
Created attachment 158124 [details] [review] alternative solution hopefully simpler solution to PWD parsing bug.
Some comments: 1) Conforming to the RFC sounds like the right thing to do. 2) I think we need proper error handling here - if we fail to parse the returned path, we should return NULL. (And the calling function(s) should handle NULL if they don't yet) 3) The function should probably not be named g_vfs_backend_create_file_from_reply() anymore, but g_vfs_backend_create_file_from_pwd_reply() or so. 4) I think I'd prefer a patch using a GString. to create the unescaped path.
(In reply to comment #3) > Hello Dimitry! > > Thanks for finding and fixing the bug. Looking at your patch I got the > impression the problem could be fixed easier then your solution. I'll post a > patch soon. Would be nice to get your comments on what you think about the > alternative solution. Well It is simpler indeed but doesn't take into account the "" (doubled quotes) inside the string which according to RFC mean the " character itself. I agree that the function must return NULL on erroneous reply.
http://git.gnome.org/browse/gvfs/commit/?id=253ffce059fc6a25ec6d58f5bace4f18ecc7f3ea ftp: Parse PWD reply according to RFC