Hi, I have been working with the FTP utilities and was saving the filename and
lastModifiedTime (as taken from FTPFile.lastModifiedTime()) and had a problem
where I would query a directory, save those two parameters for each of the
files, then later on query the same directory (which in my test case has not
changed any) and I would find that the FTPFile.lastModifiedTime() objects did
not match.
In looking furthur into it I found that the calendar objects returned by this
function were off by a some random number of milliseconds, however it looked
like the hour, minutes, and all other times of the calendar were correct, it
was only the milliseconds.
Drilling furthur into the source code for the Commons FTP components I think I
see what was overlooked to cause this condition.
In version 1.2.2 if you look at the UnixFTPEntryParser.java source (I believe
this is the parser being used for my WSFTP server I am running, you can
download this ftp server from download.com, I am using this for my development
environment), looking on line 185 you have the following code:
Calendar cal = Calendar.getInstance();
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.HOUR_OF_DAY, 0);
I see that you are initially creating a new calendar instance, which, by
default sets the calendar to the current time. Then you update the seconds,
minutes, and hour of dat, however you are not initializing the miliseconds,
hence the miliseconds vary between different instantiations of the same ftp
entry. This causes the Calendar.equals() function to indicate that the two
times are different, though they should be equal.
If you add:
cal.set(Calendar.MILLISECOND, 0);
I think you eliminate this problem.
Best regards,
David
Bug
Closed
Major
[net] FTP component: FTPFile does not initialize miliseconds correctly
This issue is currently fixed in CVS and will be available in the 1.3.0 release
of Commons-Net (due to be released next week).