Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fails to read absolute directory symlinks #4213

Closed
cyberduck opened this issue Feb 10, 2010 · 13 comments
Closed

Fails to read absolute directory symlinks #4213

cyberduck opened this issue Feb 10, 2010 · 13 comments
Assignees
Labels
bug sftp SFTP Protocol Implementation worksforme
Milestone

Comments

@cyberduck
Copy link
Collaborator

169d173 created the issue

my server's default path is a directory full of links to other directories.

when i connect via FTP, they show as folder icons with link arrows and work fine... i can double click on them in cyberduck and browse the contents of the linked directory.

when i connect via SFTP, they show as file icons with link arrows, but they don't work. i can not follow their link path.

@cyberduck
Copy link
Collaborator Author

@ylangisc commented

Can you please post the (FTP) transcript from View → Log Drawer.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:1 yla]:

Can you please post the (FTP) transcript from View → Log Drawer.

This will not help. As per the description, FTP listings work. Unfortunately, we do not have a transcript for SFTP connections. Do you succeed getting a correct directory listing with another client application?

@cyberduck
Copy link
Collaborator Author

169d173 commented

well, they show as links either way... the application should check the type of what it links to.

when i ssh directly, my shell shows them as directories and i can cd to them and everything works.

i thought SFTP was just FTP done over SSH? somewhere you aren't checking if links are directories.

@cyberduck
Copy link
Collaborator Author

169d173 commented

this might help...

from the file details:
WHERE: /home/.sites/132/site12 J"@
KIND: symbolic link (file)

the J"@ text in the WHERE might be the problem.... but the "kind" is showing as "(file)" which is also incorrect.

could i change something on my server to make it work, or do you need to fix something in cyberduck?

@cyberduck
Copy link
Collaborator Author

169d173 commented

from ls -l when i ssh to the server for the same symlink:

lrwxrwxr-x    1 root     root           20 Jul 28  2009 www.websiteurl.com -> ../.sites/132/site12

nothing in there about J"@... looks like cyberduck bug.

maybe the problem is the file name "www.websiteurl.com" that has periods in it... maybe cyberduck is incorrectly identifying it as a ".com" file instead of a link to a directory... notice the leading "l" for link in the permissions settings...

@cyberduck
Copy link
Collaborator Author

169d173 commented

and here is the FTP transcript from inside an SSH session on the server:

ftp> cd /home/sites
250 CWD command successful.
ftp> ls
227 Entering Passive Mode (208,78,244,174,201,138).
150 Opening ASCII mode data connection for file list
lrwxrwxr-x   1 root     root           20 Jul 28  2009 www.websiteurl.com -> ../.sites/132/site12
226 Transfer complete.

@cyberduck
Copy link
Collaborator Author

169d173 commented

trying to fix the newlines... they were showing right on the form...

ftp> cd /home/sites
250 CWD command successful.
ftp> ls
227 Entering Passive Mode (208,78,244,174,201,138).
150 Opening ASCII mode data connection for file list
lrwxrwxr-x   1 root     root           19 Apr  9  2005 www.websiteurl.com -> ../.sites/148/site6
226 Transfer complete.

@cyberduck
Copy link
Collaborator Author

169d173 commented

i just downloaded version 1.2 of Fugu, which is an SFTP only client... the directory symlinks worked fine and navigated to the proper directory when clicked on.

also the connections did not become stale.

your inattention to this seemingly critical, simple to fix, potential data loss causing bug has caused you to lose a user.

Fugu does not however provide back/forth history buttons... but they do provide a history list... other than that, they got you matched on features.

good luck.

@cyberduck
Copy link
Collaborator Author

GlowingApple commented

I don't know if I can shed any light on this, but I ran into this same problem.

For my particular example, I found that if the symlink was an absolute link (i.e. it linked to "/dir/dir2/dir3") Cyberduck saw it as a file and tried to download it (and subsequently failed). I then noticed that other links were being followed properly, and they were all relative links. So, once I changed the symlink to be a relative link (i.e. it now links to "../dir/dir2/dir3") Cyberduck follows it as if it were a regular directory.

Using the stock CLI sftp client, I was able to cd through the link in either case, but Cyberduck only followed it properly once it was relative.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

We now have a closer look as this didn't get the desired attention.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Can you please help with the following debug information. Open a Terminal.app window and enter

defaults write ch.sudo.cyberduck logging warn

Then, list the folder in question. In the system.log of Console.app there should be a warnig message starting with

Cannot read symbolic link target of ...

Please post the error message here.

@cyberduck
Copy link
Collaborator Author

dc6ae18 commented

Sorry for the delay, I don't think I had e-mail notification set up properly (I'm not sure it's set up properly now, but we'll see...).

I just tested this with logging set to warn and I can't duplicate the issue. I created some absolute links and relative links and other than lots of "No cached attributes for..." messages, Cyberduck followed both without error. I tried links to directories and to files. I also tried links that spanned different filesystems and they work as well.

Was this fixed in a more recent version? I'm running 3.5.1 (6117) on Mac OS X 10.6.4 (x86_64).

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:12 http://glowingapple.myopenid.com/]:

There was no change in the SFTP implementation that should affect this that I am aware of.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug sftp SFTP Protocol Implementation worksforme
Projects
None yet
Development

No branches or pull requests

2 participants