GNOME Bugzilla – Bug 117633
libssh module in gnome-vfs-2.0 no longer works as ssh doesn't allocate pty's for /dev/stderr
Last modified: 2005-02-11 23:49:57 UTC
The ssh vfs module is broken. This means you can no longer use the URI syntax ssh://server/diretcory in nautilus. My setup: % pkg-config gnome-vfs-2.0 --modversion 2.3.5 % ssh -V OpenSSH_3.6.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f I can ssh to my machine 'server' from machine 'client' without a password (ssh-agent has been pre populated appropriately) client ~% ssh server uname -a Linux server 2.4.22-pre6 #5 Tue Jul 15 12:06:24 BST 2003 i686 unknown unknown GNU/Linux However gnome-vfs fails to return the correct info for the server client ~% gnomevfs-info ssh://server Name : (null) UID : 0 GID : 0 Using 'strace' to trace the process shows this command being executed: ... 566 execve("/usr/bin/ssh", ["ssh", "-oBatchMode=yes", "-x", "-l", "mitch", "-p", "22", "server", "LC_ALL=C; echo READY > /dev/stderr;ls -ld \'/\' 2>&1; echo DONE > /dev/stderr"], [/* 31 vars */]) = 0 566 brk(0) = 0x8082e04 ... 566 write(6, "zsh: no such device or address: /dev/stderr\n", 44) = 44 564 <... read resumed> "zsh: no such device or address: /dev/stderr\n", 4096) = 44 Running the command manually shows that it also fails: client ~% ssh -oBatchMode=yes -x -l mitch -p 22 server "echo READY >/dev/stderr;ls -ld '/home/mitch' 2>&1 ; echo DONE >/dev/stderr" zsh: no such device or address: /dev/stderr This means ssh is no longer allocating /dev/fd/[02]. Using the '-t' flag on the ssh command line will make this work, however this only works since we have a controlling tty. I put this change into the ssh-method.c and recompiled but it still doesn't work. This module needs to be fixed or removed (hence i marked this bug as major) since it makes this vfs method effectively useless. I believe that we can rewrite to not require the READY/DONE stderr redirection to mark begin/end of ssh o/p by just checking for 0 bytes read() on the fd which should just signify EOF, and just use a poll() timeout for waiting for data on the stdout fd.
Anyone want to give this a try?
I can do this no problem, but don't have access to put back to cvs. Can i just do the fix and post/attach the diffs to this bug and someone else can putback ?
Yeah sure. Actually most of the bug fixes patches are generally attached to the corresponding bug so that they can get reviewed, and once they have been reviewed by the module maintainers, they go in. Thanks for working on that ;)
Okey dokey. If no one beats me to it, i should have something in a day or two.
Got a bit further with the code change. Seems to be easier that i thought. I also fixed the bug where it earlier ignored your .ssh/config file for username, hostname, port combinations. % gnomevfs-info ssh://wolf/home/mitch Name : mitch Type : Directory MIME type : x-directory/normal Size : 14336 Local : NO SUID : NO SGID : NO Sticky : NO Permissions : 600755 Link count : 229 UID : 34799 GID : 10 Access time : Wed Sep 17 18:13:00 2003 Modification time : Wed Sep 17 18:13:00 2003 Change time : Wed Sep 17 18:13:00 2003 Device # : 0 Inode # : 0 Readable : YES Writable : YES Executable : NO
Someone on advogato expressed interest in having it allocate ptys so that you could enter username/password using the standard auth dialog. That would rule. Here is the link: http://advogato.com/person/mrcsparker/
Created attachment 20137 [details] [review] Fix .ssh/config reading and the broken pty allocation
Guys please try the patch attached. I've changed the stderr READY/DONE hack to use select() instead. Not sure if it's the best way to do it but at least it works. I also fixed the module so that it honors the .ssh/config settings (if any). Report any bugs.
Can you post the patch as a unified diff (diff -u)?
Created attachment 20138 [details] [review] diff -u patch as requested.
I'm moved a bit further with this patch - but not in the same area. I've now added internal caching using a hash table to match against host/dir in order to stop making an expensive "ssh ls -l" calls to the remote server. It uses the timestamp on the dir of the first call to "ssh ls -lad" to compare if the cache is stale and refresh it. Should i log another bug and implement the caching there ? Also i've fixed another trivial bug where the ssh method ignored (or rather doesn't check for) the "show_hidden_files" setting from nautilus. Now we get the gconf bool preference and honor it if set to true for our listings. Shall i log a separate bug for this ? Has anyone had a chance to test the patch yet ?
Woo, you rock :) I haven't gotten a chance to try your patch yet, I'll try to do it this week. If you could file separate patches in new bugs for your other improvements, that make things easier to review (if the patches are too painful to split, don't bother, and file a big patch here). Isn't the show-hidden-file setting supposed to be handled by nautilus rather than by gnome-vfs ?
I forgot to mention that Chris S. Parker was also doing some work on the ssh method, you might want to coordinate with him to avoid painful conflicts: http://mail.gnome.org/archives/desktop-devel-list/2003-September/msg00740.html
Hi Chris, yes the "show-hidden-file" setting is handled by the nautilus Preferences settings, but the ssh vfs module doesn't even consult the setting and always calls "ls -l" - instead of "ls -la" to show hidden files if the boolean setting is true. Thanks about the tip about Chris Parker. I'll contact him shortly.
hidden files are not meant to be handled by the gnome-vfs module. You don't know that nautilus is the one using the module. e.g. vfs-ls as shipped with gnome-vfs must also work. Furthermore, that gconf setting is scheduled to be removed in favour of per-window settings of show-hidden-files. Also, gconf isn't threadsafe, so it can't be used as-is in a vfs backend without a lot of care. I posted about how to do this to the list a while ago.
I started to look at your patch. First I massaged it a bit since it didn't compile (gcc 3.3 from debian), mainly because of the (host_port ? " -p ", host_port : "") constructs. I switched that part to using GString, this probably makes the code more readable. I also readded the LC_ALL since it's needed to get a parsable output from ls in non C locale. In ssh_read, the (retval == 0) case is unhandled, is that intentional ? Finally, I don't exactly understand how this select thing works when it tries to read from the error fd (which happens after each time it runs a command). I would have expected to have a 5 seconds delay after each command execution, but it didn't happen during my test. Is that because when there is no error, we get an eof on the error fd, and so select returns and doesn't need to timeout? The patch I'm going to attach is working reasonably well, so I'm committing it to HEAD.
Created attachment 20791 [details] [review] slightly modified version of the patch attached previously
The ssh method has been removed from cvs some time ago. So I am closing this bug as a WONTFIX.