Community
Participate
Working Groups
I have installed RSE in Eclipse 3.2 & have connected it to a target solaris Unix m/c as FTP. The Remote file system shows all the folders & most of the folder get opened . But when I try to open a mounted folder say Clearcase VOB folders , they do not open up properly. The folder does not show any children. But when I am using any normal ftp utility I am able to access these folders. So I need to know why this is not opening in RSE & Is there any solution or workaround to the issue
We'll need more information to proceed. 1.) TM 2.0 is tested against Eclipse 3.3 only -- can you test on Eclipse 3.3? 2.) Attach the output of the FTP Console log (Window > Show View > Console, then click on the computer icon to select the FTP Console). This will also tell us what kind of FTP server you are using. 3.) Any exceptions logged? (Window > Show View > PDE Runtime > Error Log) A log of successfully opening mounted folder on commandline versus the log of not opening that same folder in RSE would also be helpful.
Created attachment 74529 [details] This file contains the detail in console
Created attachment 74530 [details] PDE Error log The pDE error log does not show any error messages
Created attachment 74531 [details] The screen shot of Remote system voew
I have used eclipse 3.3 & the same thing happens here also.. Please find the attached docs
I have tried it on eclipse 3.3 Still not success. I have attached the files.
I have tried it on eclipse 3.3 Still not success. I have attached the files. The directiry that gives issues is /view
The log seems to indicate that your FTP server just does not return anything for the contents of /view. Please try exactly the same on a commandline ftp client, and attach the output of your FTP client: ftp ebizdev user r1081z cd /view dir Javier - we've had similar requests already, could we improve the FTP console logging so that we get the actual result of the LIST query printed to the console as well? If you agree, please file an enhancement request for improving FTP logging.
Created attachment 74539 [details] command lint ftp output
As you see in the ftp output when I do a ls after CD View , I get a list of directories displayed
The problem is the format in which the files are listed. Even if you have a custom parser, there's some useful data that is missing (such as if the entry is a file or a folder and its size, permissions and creation date) Can't you specify a "unix" like output in the server instead?
(In reply to comment #10) I asked you to type "dir" and not "ls". This should produce a more useable output format. And it is what we do in the RSE client.
(In reply to comment #8) > could we improve the FTP console > logging so that we get the actual result of the LIST query printed to the > console as well? If you agree, please file an enhancement request for improving > FTP logging. > I have created bug 197766 (Improve FTP console showing LIST output)
Created attachment 74542 [details] ftp output -- dir I hope this is the output u required
Javier -- I guess the listing parser is confused by this entry at the beginning of the /view directory (note the 0, 0 entry where there should be a size): cr--r--r-- 2 root root 0, 0 Jul 25 03:31 .specdev drwxr-xr-x 56 a13581 dev 1536 Jul 23 11:08 a13581_Mar_2007_dev I'd say that this is a bug in the Jakarta Commons Net FTP Parser which we are using. Looking at their issue tracking system at http://jakarta.apache.org/commons/net/issue-tracking.html I found this bug which is similar but not quite the issue: http://issues.apache.org/jira/browse/NET-25 Apparently the UnixFTPEntryParser.REGEX is missing the case where instead of the size we get n,n for the major,minor of a device. We should file a bug against Commons Net for this, especially because the listing parser stops all operation for the given directory -- it should at least better just ignore such an entry if it cannot parse it. Javier can we work around this in RSE? E.g. subclass the UnixFTPEntryParser or modify the DefaultFTPEntryParser to be more fault tolerant and continue parsing if a single entry is invalid? Or even modify the regex to understand the 0,0 format for UNIX special devices? I modified the summary (old value: "Solaris mounted folders do not open up")
(In reply to comment #15) > Javier can we work around this in RSE? E.g. subclass the UnixFTPEntryParser or > modify the DefaultFTPEntryParser to be more fault tolerant and continue parsing > if a single entry is invalid? Or even modify the regex to understand the 0,0 > format for UNIX special devices? Subclassing UnixFTPEntryParser in a similar way as we have done for WindowsNT and VMS seems the faster solution. Do you know any available FTP server with this behaviour so I can test a fix ?
I guess you can use just any FTP server on UNIX, and do cd /dev then list the contents. If you dont have a UNIX ftp server I can also test it. BTW, I just tried this with CuteFTP client against my ftp server, and it just silently ignores all the character and block special devices, supposedly for exactly the same reason. So the real problem with Commons Net is just that it stops parsing the entire stream just because of an error in a single line. I agree that I'd prefer a workaround fix in RSE, but we should file a bug against Commons Net none the less.
(In reply to comment #17) > I guess you can use just any FTP server on UNIX, and do > cd /dev > then list the contents. If you dont have a UNIX ftp server I can also test it. > > BTW, I just tried this with CuteFTP client against my ftp server, and it just > silently ignores all the character and block special devices, supposedly for > exactly the same reason. So the real problem with Commons Net is just that it > stops parsing the entire stream just because of an error in a single line. > > I agree that I'd prefer a workaround fix in RSE, but we should file a bug > against Commons Net none the less. > I'm using vsFTPd 2.0.1 on Linux and the devices in /dev are listed as (subset): crw-rw---- 1 0 5 0 Jul 18 11:23 tty9 crw-rw---- 1 0 14 0 Jul 18 10:24 ttyS0 crw-rw---- 1 0 14 0 Jul 18 11:23 ttyS1 crw-rw---- 1 0 14 0 Jul 18 11:23 ttyS2 crw-rw---- 1 0 14 0 Jul 18 11:23 ttyS3 crw-rw---- 1 0 14 0 Jul 18 11:23 ttyS4 which is correctly parsed and displayed as files in the RSE tree. I'll update the regexp to support lines like: cr--r--r-- 2 root root 0, 0 Jul 25 03:31 .specdev But it would be much helpful if I could access a server with this behaviour.
It seems that this is specific to Solaris targets. I also could not reproduce it with ProFTPd on Linux, but I can on Solaris: Y:\>ftp schnibble Connected to schnibble.takefive.co.at. 220 schnibble FTP server ready. User (schnibble.takefive.co.at:(none)): mober 331 Password required for mober. Password: 230 User mober logged in. ftp> literal syst 215 UNIX Type: L8 Version: SUNOS ftp> cd /devices 250 CWD command successful. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 68 drwxr-xr-x 4 root sys 512 Jul 2 2004 pci@1c,600000 crw------- 1 root sys 109,767 Jul 2 2004 pci@1c,600000:devctl 226 Transfer complete. ftp: 738 bytes received in 0.00Seconds 738000.00Kbytes/sec. ftp> Perhaps we could tie the special handling to "Version:SUNOS". Again, I can test any patches you provide. And again, I'd recommend avoiding the stop of parsing all the rest of the directory in case just a single error occurs, in addition to fixing the regex.
Looks like you'll need to change the regex to: + "(\\d+(?:,\\s*\\d+)?)\\s+" /* numeric or standard format date */ in order to account for the optional ,n
(In reply to comment #20) > Looks like you'll need to change the regex to: > > + "(\\d+(?:,\\s*\\d+)?)\\s+" > > /* > numeric or standard format date > */ > > in order to account for the optional ,n > The main problem is that the regular expression is a private final member in org.apache.commons.net.ftp.parser.UnixFTPEntryParser so extending to overwrite the regexp is not possible. The best solution would be having it fixed in the Apache Commons Net package, but it might take some time. As a workaround, the functionality of the Unix parser can be implemented in a class like org.eclipse.rse.internal.subsystems.files.ftp.parser.RSEUnixFTPEntryParser using the fixed regular expression.
I'm not sure if we can copy & paste Apache code without detailed copyright / IP investigation. I'm more in favor of deriving from UnixFTPFileEntryParser, and overriding it to catch parsing exceptions such that it continues with the next entry (i.e. the offending entry would be silently ignored, which is what other FTP clients already do). In addition to that, of course file a bug against commons net.
(In reply to comment #22) > I'm not sure if we can copy & paste Apache code without detailed copyright / IP > investigation. I'm more in favor of deriving from UnixFTPFileEntryParser, and > overriding it to catch parsing exceptions such that it continues with the next > entry (i.e. the offending entry would be silently ignored, which is what other > FTP clients already do). > > In addition to that, of course file a bug against commons net. > In this case, it should be possible just catching the exception and not show the entry in the RSE tree. What could be done is listing the device in the console, as part of the LIST output, but ignoring the entry if it doesn't match the regular expression.
sounds good to me. Plus the bug against commons net.
Created attachment 74597 [details] Patch Martin, can you verify the patch works ? It should ignore the Solaris device entries with versioning, as I suspect before were causing NPE. I have added some extra code to show the listing in the console, but at the moment only the successfully parsed file entries are shown.
Yes the patch works for me. Cool! Feel free to commit it.
The one issue I do see is that symbolic links are not reported as symbolic links but rather as files. These should be reported with a classification of "symbolic link(file) to /link/target". See the SSH implementation for reference: SftpFileAdapter / SftpRemoteFile which overrides getClassification(), and SftpHostFile.getClassification() for reference. Adding this in 2.0.1 would be possible since FTPHostFile is "internal" so it's no API change. Commons Net gives the required information with FTPFile.isSymbolicLink() and FTPFile.getLink() already. A separate enhancement request for that feature should be filed.
Patch applied
(In reply to comment #27) Enhancement request for correct symlink classification filed as bug 198272.
Apache Commons Net is now aware of the issue: https://issues.apache.org/jira/browse/NET-201
Comment on attachment 74597 [details] Patch iplog- since Javier was committer since Aug 2006 already: http://dev.eclipse.org/mhonarc/lists/dsdp-tm-dev/msg00375.html
