FTPClient listFiles returns incorrect timestamp on freshly uploaded file but
corrects itself after about 15 minutes
-------------------------------------------------------------------------------------------------------------------
Key: NET-140
URL: http://issues.apache.org/jira/browse/NET-140
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Windows local client site, Linux remote server site
Reporter: Bill Giel
This is an odd one:
We upload GPS data each hour to a public site using FTPClient. Every 24 hours
we check for files older than 60 days using listFiles and getting the
timestamps do decide if we want to delete older files.
When we list the files, the most recently uploaded files have a time stamp
exactly one year too old. After about 15 minutes, it seems to correct itself
and eventually displays the correct timestamp.
During this time while FTPFile.getTimestamp is giving the incorrect timestamp,
browsing the folder with a web browser, a commercial FTP client, or actually
checking the file info in a shell shows the correct timestamp (i.e. does not
seem to be a problem on the remote site)
commons-net-1.4.1 (as well as commons-net-20060901) exhibits this behavior.
commons-net-1.3.0 works properly
I did a little investigating, and it seems to happen with every file written to
the remote directory each hour, and the incorrect timestamp will be returned
using listFiles for about 15 minutes... and then it corrects itself.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
