GNOME Bugzilla – Bug 330625
sftp crashes on clicking any folder with files once connected
Last modified: 2007-01-07 13:03:35 UTC
Steps to reproduce: 1. sftp to a windows server running freesshd (version 1.09 at time of writing) 2. double click any folder that you see once connected 3. nautilus will immediately crash Stack trace: 0xffffe410 in __kernel_vsyscall ()
+ Trace 66054
Thread 1 (Thread -1225783616 (LWP 16081))
Other information: I am able to sftp to another linux machine. I can use winscp to connect to this freesshd server so I don't think it's the server.
This sftp connection works in konqueror
I also found out that Nautilus only crashes if the folder I double-click contains files. If the folder has another folder, or is empty, alls well.
Thanks for the bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so.
Any chance I can set up the windows sftp server side of things and let someone login to produce the crash themselves? I should also note that this is with Nautilus 2.14.2 now
Distribution: Mandriva Linux release 2007.0 (Cooker) for i586 Gnome Release: 2.15.91 2006-08-08 (Mandriva) BugBuddy Version: 2.15.90 Memory status: size: 110534656 vsize: 0 resident: 110534656 share: 0 rss: 23855104 rss_rlim: 0 CPU usage: start_time: 1155920895 rtime: 0 utime: 3307 stime: 0 cutime:3165 cstime: 0 timeout: 142 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/nautilus' Using host libthread_db library "/lib/i686/libthread_db.so.1". `shared object read from target memory' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1227470528 (LWP 16248)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 70676
Thread 1 (Thread -1227470528 (LWP 16248))
To test. sftp://bug:bug@burner.ath.cx I put just a simple blah.txt file two directories down so you can see that directories with only directories work.
Using the shell, I tried sftp bug@burner.ath.cx Logging in with the specified password and entering ls yielded this folder has folders in it How is this supposed to reflect a valid response to the opendir/readdir command set. Granted, we shouldn't crash (and for me, gnomevfs-ls/nautilus just hang/do nothing), but what crappy server is this supposed to be?
The ls seems to me the same as under a openssh sftp. ls -l seems fine and almost the same as ls -l under openssh (user+group field seems a bit further away).
Of course it yielded "this folder has folders in it" because that's what I named it... when you 'cd' into that "folder" there's a folder named "this folder has files in it" and inside that there is a "blah.txt" it's when you try to get the directory listing of the "this folder has files in it" folder via nautilus that nautilus dies. I did this to demonstrate it works with folders, but not when files exist in that folder. This server is strictly set up for testing purposes. I couldn't grant access to the real server I use this on. :)
Sorry, I thought this would be a SSH_FXP_STATUS response. Unfortunately, I'm currently unable to connect to burner.ath.cx. Port 22 seems to be filtered.
Stability isn't the same. This is on a windows XP box on my personal home connection. Please keep trying. If I ever notice it down, I will restart it.
*** Bug 354703 has been marked as a duplicate of this bug. ***
Derek: Sorry, I didn't have time yet. The provided credentials don't seem to work anymore, though. Maybe you could reactivate the account? If your server experienced attacks, we can also make the bug report "private" (i.e. only GNOME hackers and you will be able to read it).
i started experimenting with edgy on this pc and wasn't booted into windows. please find me on irc sometime if you'd like other end help in debugging. irc.freenode.net or irc.gnome.org as 'bur[n]er'
I setup freesshd myself and discovered that this is a GnomeVFS issue, in sftp-method. The server doesn't provide any recognized stat mode in SSH2_FILEXFER_ATTR_PERMISSIONS, so we have GNOME_VFS_FILE_TYPE_UNKNOWN. The logic will use gnome_vfs_mime_type_from_mode which returns NULL for unknown stat modes. However, Nautilus won't accept NULL MIME types when GNOME_VFS_FILE_INFO_FIELDS_MIME_TYPE is present. Reassigning to GnomeVFS.
Created attachment 72499 [details] [review] Proposed patch The patch adds gnome_vfs_mime_type_from_mode_or_default, uses it in sftp/ftp method and includes spin-off fixes that check for info->valid_fields & GNOME_VFS_FILE_INFO_FIELDS_TYPE in some places.
I'm also experiencing this bug in Ubuntu Edgy knot3. It's not possible to access folders on my Windows machine running freesshd. It mounts it correctly, but when I log in it crashes. Has the proposed patch been applied? If it has, I would like to know which version of Gnome has the patch. Thanks
The patch has been reviewed by Alex, he was a bit sceptical about the new API. See http://mail.gnome.org/archives/gnome-vfs-list/2006-September/msg00007.html
Created attachment 73574 [details] [review] Committed patch (without new API). This patch has just been committed, it doesn't introduce new API but handle NULL retvals manually. Let's introduce the clean solution (i.e. involving new API) when after branch.
Created attachment 73575 [details] [review] New patch (to be committed after branching, HEAD only) The attached patch cleanly implements a gnome_vfs_get_mime_type_from_mode_or_default variant of gnome_vfs_get_mime_type_from_mode.
Setting patch status to "committed" resp. "accepted-commit_after_freeze".
Created attachment 79620 [details] [review] Patch to partially revert the last (committed) patch OK, this one partially reverts the last patch. We didn't pass the stat mode but only a subset of it (the permissions part) to gnome_vfs_mime_type_from_mode so it never recognized the MIME type from mode.
Reopening as not all patches have been committed.
Committed the new patch, applying a similar fix as proposed in comment 22. Closing bug report.