Bugzilla – Full Text Bug Listing
| Summary: | [ftp] Files changed on 29th February cannot be viewed in the RSE | ||
|---|---|---|---|
| Product: | [Tools] Target Management | Reporter: | Fabian Guth <fabian.guth> |
| Component: | RSE | Assignee: | Martin Oberhuber <mober.at+eclipse> |
| Status: | RESOLVED FIXED | QA Contact: | Martin Oberhuber <mober.at+eclipse> |
| Severity: | normal | ||
| Priority: | P3 | CC: | aceler, dmcknigh, fabian.guth, kjdoyle, lexattacks, niklas, test1 |
| Version: | 2.0.3 | ||
| Target Milestone: | 3.1 M7 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 267473 | ||
| Bug Blocks: | |||
|
Description
Fabian Guth
(In reply to comment #0) > Files and Folders disappear in the RSE if the change date is the 29th February. > > Steps to Reproduce: > 1. View a file changed on a different date (in RSE) > 2. Edit and save it with Eclipse or every other Program > 3. the file disappeared > > > Tomorrow i will test, if they appear again, when edited on 1st March > > P.S: This is my first bug report, so please dont criticise it (and my English) > too much :-) > recognized same behavior on my system. This only happens on ftp. The file is not deleted, but disconnecting and reconnecting won't get it to show up again. Connecting to the same system through sftp and I can see the file. Ha ha, very funny ... I first thought it was a too-early april's fool joke but it apparently isn't. What FTP server are you testing with? What does the FTP console log show? What happens if you use a commandline FTP client? It looks like the REGEX patterns that commons.net.ftp uses for parsing the date fail for Feb 29th. Which would be an ugly commons.net bug, but fortunately they are talking about a 1.4.2 release right now... No. I didn't joke :-) Ok. Yes it happens only on ftp. (server ftp.strato.de) With other ftp-Clients (e.g. Filezilla) i could see and edit the file, but not with RSE. In the Console-Log, the file doesn't show up in the files-list. e.g LIST 150 Opening ASCII mode data connection. 226 Transfer complete. Closing data connection. -rw-r--r-- 1 ftp ftp 68289 Aug 25 2007 forum.PNG -rw-r--r-- 1 ftp ftp 24 Sep 1 2007 test2.php but the file test.php with the date of 29th Feb is missing. I also tried to restart, to delete all Connections (in RSE) and create new ones, but it hdoesn't help. What I noticed is in FTPService.listFiles we have this:
public void run() {
try {
_ftpFiles = null;
if(_clientConfigProxy!=null)
{
>> _ftpFiles = _ftpClient.listFiles(_clientConfigProxy.getListCommandModifiers());
}
If I create new files (via telnet) on the remote system, then each of those files appears as null in the _ftpFiles array. So it does look like a problem with org.apache.commons.net.ftp.FTPClient
update to the recent version (2.0.3v20080225) didn't help either. Last post for today (i hope, tomorrow it will work again) Stepping through the apache code, I see where we hit the exception:
org.apache.commons.net.ftp.parser.UnixFTPEntryParser.parseFTPEntry(String)
try
{
file.setTimestamp(super.parseTimestamp(datestr));
}
catch (ParseException e)
{
return null; // this is a parsing failure too.
}
Actually, it looks like the problem may be in java.text.SimpleDateFormat.parse() Having debugged it, can you attach the String that's failing to parse, as well as the backtrace from the Exception? You should be able to set a Java Exception Breakpoint for ParseException . Also, what JVM are you using? I think the least we can expect from commons.net is that when they cannot parse an entry, they don't return null but at least return the RAW line from the ftp server. I'll check their bug tracking system to see if they have such a bug. I've been reproducing this with both the Sun java 5 JVM and the IBM 5 JVM. The entry that fails to parse is this: -rw-r--r-- 1 7639 1001 0 Feb 29 15:23 zzz.c It looks like an IllegalArgumentException(String s) is constructed with "MONTH" in GregorianCalendar.computeTime(). Perhaps because it doesn't know that the year in question is 2008 ? If it thinks it should compute for a year that has no Feb. 29th it should be lost... Your String does not specify a year, I assume this is the problem. (In reply to comment #13) > Perhaps because it doesn't know that the year in question is 2008 ? If it > thinks it should compute for a year that has no Feb. 29th it should be lost... > Your String does not specify a year, I assume this is the problem. I do see that this one works: "drwxr-xr-x 2 7639 1001 104 Oct 18 13:44 largefiles" When I changed the failing string to this (i.e. inserted the year): "-rw-r--r-- 1 7639 1001 0 Feb 29 2008 zzz.c" it does work. Also if I changed the failing stirng to this (i.e. changed from the 29 to 28): "-rw-r--r-- 1 7639 1001 0 Feb 28 15:23 zzz.c" it works too. It acutally *is* a commons.net bug: https://issues.apache.org/jira/browse/NET-188 And it looks like it's been fixed in an upcoming commons.net 1.5 release: http://mail-archives.apache.org/mod_mbox/commons-dev/200803.mbox/ajax/%3c47CB1EBA.6040608@eircom.net%3e as well as 2.0 release: http://mail-archives.apache.org/mod_mbox/commons-dev/200803.mbox/ajax/%3c47CB1F81.2090306@eircom.net%3e So that's nothing which could be fixed on bugday. *** Bug 221148 has been marked as a duplicate of this bug. *** since commons net version 1.5 and 2.0 are out for a while, can we upgrade RSE to use new version of commons net? Commons Net 1.5 has not yet been released. Commons Net 2.0 has been released, and is available from Orbit today: http://download.eclipse.org/tools/orbit/downloads/drops/S20090307012903/ IP Legal review for re-using is is still pending for TM: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=3188 But the code has been updated already to work with Commons Net 2.0. So, TM 3.1m6 will still be shipped with Commons Net 1.4.1 but you will be able to download the 2.0 version from Orbit and TM will automatically pick it up and use it. I'm confident that we can integrate Commons Net 2.0 with M7. This should be fixed by migrating to Commons Net 2.0 as per bug 267473. The issue is a little hard to reproduce, since the problem appears only if the CURRENT DATE on the FTP server is also in a leap year. That is, Files changed on Feb 29, 2008 vanished if server time was also in 2008 and thus the directory listing was "short" without displaying the year. After playing some 15 minutes trying to verify, I'm closing this being optimistic that it should work thanks to commons net 2.0. |