Community
Participate
Working Groups
I am using Remote systems to connects to unix sun os system. The system get connected & am able to see the folder structure. In the home directory I have created a lint to another folder using unix ln command.. When I look at this link in Remote Syystem View in eclipse it shows a file not as a folder Please let me know what is the issue
What protocol are you using? This is known to work properly in SSH, so I assume you use FTP? Do you have evidence that other (FTP) clients do properly show your symbolic link?
Yes as U have assumed I am using FTP. I have used other FTP softwares like Cute FTP, FTP commander which works perfectly fine. There are no issues in them
The problem is, when the FTP clients retrieves a directory listing it gets information that an item is a symbolic link; but from that listing it does not immediately know whether the link points to a file, points to a folder or is broken. In order to properly classify the link, it would need to read the link target, and follow it. This is too slow in a client/server scenario. I assume that your other FTP clients (CuteFTP, FTP Commander) are just set up to always treat symbolic links like folders or they use some pattern (e.g. if the link has an extension like foo.txt, treat it as a file otherwise treat it as a folder). Please try out your clients: ssh remotehost cd $HOME ln -s /notExisting linkBroken ln -s /existing/folder linkFolder ln -s /existing/folder linkFolder.txt ln -s /existing/file linkFile ln -s /existing/file linkFile.txt and specify the behavior you would like to see for showing the links as a folder vs. as file. I'm open to modifying the FTP client, provided that we get a specification for the expected behavior. I tested this with CuteFTP, and in fact it shows - symbolicLink as folder when it has no extension - symbolicLink.txt as file if it contains any dot (.) in the name and does so also if the link is actually broken. This is not a bad fallback, but it still fails if you have symbolic links like my.dir pointing to a directory. Is this what you want? i.e. treat symbolic links as folder when there is no dot in them and as file when there is a dot in them?
Yes , Even if we could treat symbolic links as folder when there is no dot in them and as file when there is a dot in them would be very helpful. Majority of the symbolic links will normally lead to a folder
Created attachment 74672 [details] patch showing symbolic links as folders when the destination folder exists I came with a quite good solution to show symbolic links as files or folders. Attempting to change the working directory to the destination of the link and reverting if successful verifies that the destination is a folder, so the FTPHostFile can be modified to be shown as a folder. It works fine with my linux FTP server, can you verify it works also for you in your environment ?
Hm.... I'm worried about performance. You'll need an extra client-server turnaround for each and every symbolic link encountered. I think I'd rather go with the "dot included" heuristics, or perhaps make it a User Preference whether they want to classify by heuristics or by "cd" method.
(In reply to comment #6) > Hm.... I'm worried about performance. You'll need an extra client-server > turnaround for each and every symbolic link encountered. I think I'd rather go > with the "dot included" heuristics, or perhaps make it a User Preference > whether they want to classify by heuristics or by "cd" method. > Since RSE caches files, the LIST command and parsing is not performed every time the user expands a folder, but when expanding I haven't seen any performance issue. I'll check if there's any delay with external FTP servers.
Of course it's not an issue in the normal case where you have a fast nearby server and not more than e.g. 5 symbolic links in a directory. But we have cases where users create "shadowed" workspaces where each and every file in a directory is in fact a symbolic link to the real file in another workspace. You can have 200 symbolic links in a directory and the server can be far away. I do not need to actually test this to know that it simply cannot scale.
I also like the idea of doing the same as a commercial FTP client by implementing the "no dot" heuristics. We could even make the pattern matcher for the heuristics configurable. But I definitely don't like the idea of having a separate server roundtrip for each and every symbolic link (unless the user configured it to have it this way).
Also note that as per http://wiki.eclipse.org/Version_Numbering a change in functionality that could lead to major change in performance would need a minor (#2) version number increment. Which we do not want right now, we just want a bugfix. So I think we'll need to go with the heuristics for 2.0.1 and we can think about adding the "cd" mechanism as a new feature for 3.0 -- you could file a separate enhancement request for that.
Created attachment 74912 [details] Patch showing symbolic links as folders when they contain no dots This patch modifies the default behavior of showing all symbolic links as files. When the symbolic link name contains no dots, it will be shown as a folder instead of a file. This way, it follows the same logic of other FTP clients, as Martin said before.
Patch is ok for this particular issue -- feel free to apply the patch. Though I'd like to see symbolic links represented even better. I have filed enhancement request bug 198272 for that.
Patch applied
Comment on attachment 74912 [details] Patch showing symbolic links as folders when they contain no dots iplog- since Javier was committer since Aug 2006 already: http://dev.eclipse.org/mhonarc/lists/dsdp-tm-dev/msg00375.html
