GNOME Bugzilla – Bug 167329
FTP ls parse fails with a Mac OS X server
Last modified: 2008-09-06 18:59:44 UTC
Please describe the problem: Part of (if not most of) the blame is no mac for this one. Gnome-vfs tries to get a directory list by running the command 'ls -aL' on the remote server. The mac osx server responds with the error "usage: ls [-1ACFRTacdfloqrstu] [file]", which of course is not a parse-able directory listing. This bug also effects gFTP. This bug might also be the result of a miss-configured ftp-server (I don't know, it's not my server that has the problem) Steps to reproduce: Connect to a Mac OS X FTP server running Mac's ftp server (Response before login: "<hostname> FTP server (Version: Mac OS X Server) ready.") in nautilus by going to File -> Open Location -> Ftp|Public Ftp. Actual results: Nautiuls will succsessfully connect to the site, but the nautilus window for the ftp site is blank. A look at ~/.xsession-errors if using gdm, or at the console from which X was launched if not using a display manager reveals the error: "(nautilus:21640): libgnomevfs-WARNING **: Could not parse: usage: ls [-1ACFRTacdfloqrstu] [file]" Expected results: See above Does this happen every time? Yes Other information: A work arround for this is for gnome-vfs to reconize the response "usage: ls [-1ACFRTacdfloqrstu] [file]" and try again with different options which return nearly the same thing, "ls -Al".
Thanks for your bug report! This will most likely be fixed once the patch from bug 48427 has been committed.
Does it work with GnomeVFS 2.12?
Still exhibits the same behaviour with gnomevfs-2.12. This is a bug with the Mac OS X FTP server, but I feel that gnomevfs should have a workaround in case it encounters a broken server like I did. A workaround could be as simple as trying different ls command parameters if the previous result was not parse-able.
As you can see from attachment 47132 [details] [review], we *are* using "LIST -a" and if that fails "LIST". Maybe you could try to debug this further with debug statements?
I'm only just learning C, but from my simple experiments, it would seem that while get_list_command is called, conn->list_command isn't used. As if you set conn->list_command to something random (something like BANANA, aka random nonesense) at the end of the get_list_command function, everything still works with a proper ftp server, and still fails with the same ls parse error on the macosx server with which I am having trouble. I've inserted numerious printf's to print the value of conn->list_command, all showing that the correct (or purposely incorrect) command is as I think it is. A grep for 'LIST ' only reveales the code in get_list_command and some commented-out code.
Maybe you could add the statement g_message ("Using OSX command: %d, result: %d, command %s", (candidates == osx_candidates), result, conn->list_cmd); to get_list_command right before the return statement and recompile GnomeVFS? If you don't feel like doing so, you can also enter p candidates p osx_candidates p result p conn->list_cmd in your debugger before the return takes place.
Also, this osx_candidates thing might be in vain, as the server which caused me to report this bug (which I don't own or have any control over, its www.fkss.ca (login required)) reports itself to be "UNIX Type: L8 Version: BSD-199506". It always barfs if you send it the -L switch on LIST.
Ok, found two logical problems with the code. The first is that the while condition for the do loop at ~2320 uses the instruction *++candidates, which means that when the successful list command is found, it is the next list command candidate that is storred in conn->list_cmd. This can be fixed by changing the line 'conn->list_cmd = *candidates;' to 'conn->list_cmd = *--candidates;.' The second problem is that the while loop also checks to see if sending the candidate command returns the value of 4 (GNOME_VFS_ERROR_INVALID_PARAMETERS), which is never returned. As far as I can tell, checking the return of do_transfer_command is useless in terms of parameters. If one executes FOO (not a real command) it returns 3, if one executes 'LIST -aL' it returns 0, if one executes 'LIST -@' (-@ being an invalid parameter) it returns 0. What is needed is for the code to check the directory listing returned for strings such as 'usage: ' and '/bin/ls ' which are the start of common syntaxual error responses, and then try different parameters. I'm not intirely sure how to do this, so far all have been able to do is create code which printf's that the directory listing received is an error response, but not do anything else. if (strstr(dirlist_str, "usage: ") || strstr(dirlist_str, "/bin/ls")) { g_message ("Dir listing is an syntaxual error response."); } So I'm hoping someone else can try and fix this.
Thanks for your investigation. You are right that get_list_command is buggy. 504 Command not implemented for that parameter. should be returned by the FTP server, though. I hope newer FTP servers obey the FTP RFC, this one is really broken.
Reopening as per latest comments.
gnome-vfs has been deprecated and superseded by gio/gvfs since GNOME 2.22, hence mass-closing many of the gnome-vfs requests/bug reports. This means that gnome-vfs is NOT actively maintained anymore, however patches are still welcome. If your reported issue is still valid for gio/gvfs, please feel free to file a bug report against glib/gio or gvfs. @Bugzilla mail recipients: query for gnome-vfs-mass-close to get rid of these notification emails all together. General further information: http://en.wikipedia.org/wiki/GVFS Reasons behind this decision are listed at http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00899.html