GNOME Bugzilla – Bug 153679
sftp symlink support is broken
Last modified: 2006-06-20 16:34:37 UTC
Something is wrong with symlinks in sftp://: * cd /tmp * mkdir test * ln -s test link-test * $ gnomevfs-ls file:///tmp | grep link-test link-test [link: /tmp/test ] (Directory, x-directory/normal) size 4096 mode 2755 $ gnomevfs-ls sftp://localhost/tmp | grep link-test link-test [link: (null) ] (Symbolic Link, x-special/symlink) size 4 mode 120755 Apparently the first result is fine, the second is not. As a result with nautilus the symlink is display as default file icon instead of a folder one. It breaks also the new gtk fileselector which return an error when you try to follow the link. (This is with gnome-vfs 2.8.1)
The fact that [link: (null)] is really bad: this means the symlink_name isn't set in GnomeVFSFileInfo, and this causes crash in gnome-vfs-xfer.c when trying to copy a directory containing a symlink because it doesn't expect this field to be NULL on a symlink.
*** Bug 166799 has been marked as a duplicate of this bug. ***
Here are the juicy bits of the resulting crash (easy to reproduce if you copy a directory with symlinks in it from an sftp mount):
+ Trace 56272
The sftp method never executes SSH2_FXP_READLINK and so doesn't set symlink_name. Instead it does SSH2_FXP_REALPATH in do_get_file_info() when FOLLOW_LINKS is set, which doesn't look right to me either.
*** Bug 167224 has been marked as a duplicate of this bug. ***
*** Bug 168798 has been marked as a duplicate of this bug. ***
Thanks for tracking it down to symlinks, Sebastien and thanks Martin for detecting the duplicate. I was just about to look into it.
*** Bug 300455 has been marked as a duplicate of this bug. ***
*** Bug 153066 has been marked as a duplicate of this bug. ***
Created attachment 46283 [details] [review] Proposed patch (against HEAD). This patch should at least improve symlink handling. Besides it IMHO fixes a potential "real_path" leak. - Do we have to care for circular symlinks INSIDE the modules? - Do we have to recursively resolve symlinks?
Comment on attachment 46283 [details] [review] Proposed patch (against HEAD). Hrm doesn't seem to work properly.
*** Bug 308585 has been marked as a duplicate of this bug. ***
*** Bug 301546 has been marked as a duplicate of this bug. ***
*** Bug 312711 has been marked as a duplicate of this bug. ***
*** Bug 313115 has been marked as a duplicate of this bug. ***
any news on a revised patch?
*** Bug 302402 has been marked as a duplicate of this bug. ***
Working on that one ...
latest duplicate is 2.11.x , adjusting version fields
*** Bug 310632 has been marked as a duplicate of this bug. ***
*** Bug 325028 has been marked as a duplicate of this bug. ***
> Working on that one ... Ping.
*** Bug 332763 has been marked as a duplicate of this bug. ***
The latest duplicate above had a slightly different stack trace, but described the same problem as this bug. If it can be useful check out the stack trace in bug 332763
Looks like sftp never sets the symlink name (how does one get the file name belonging to a handle, btw.?), and the xfer code assumes that if the file type is GNOME_VFS_FILE_TYPE_SYMBOLIC_LINK, the symlink name is automatically valid, which is not the case.
Created attachment 61461 [details] [review] Proposed patch Discussion: http://mail.gnome.org/archives/gnome-vfs-list/2006-March/msg00025.html
This patch works great for me. Thank you.
*** Bug 318983 has been marked as a duplicate of this bug. ***
*** Bug 336618 has been marked as a duplicate of this bug. ***
May I ask, what the situation is regarding this patch? Could it be something for GNOME 2.14.1 or is it deemed to be 2.15 material?
A patch based on attachment 61461 [details] [review] was committed to GnomeVFS 2.15 [1], it is not very well-tested though. What are you waiting for? :) [1] http://mail.gnome.org/archives/gnome-vfs-list/2006-April/msg00021.html