[
https://issues.apache.org/jira/browse/NET-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694758#action_12694758
]
Rory Winston commented on NET-140:
----------------------------------
Hi James
Could you provide some examples of the files in question (i.e. would you be
able to provide the raw output from an FTP listing)?
> FTPClient listFiles returns incorrect timestamp on freshly uploaded file but
> corrects itself after about 15 minutes
> -------------------------------------------------------------------------------------------------------------------
>
> Key: NET-140
> URL: https://issues.apache.org/jira/browse/NET-140
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: Windows local client site, Linux remote server site
> Reporter: Bill Giel
> Fix For: 2.0
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
