Return-Path: Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: (qmail 97994 invoked from network); 2 Apr 2009 02:17:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Apr 2009 02:17:34 -0000 Received: (qmail 3513 invoked by uid 500); 2 Apr 2009 02:17:34 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 3395 invoked by uid 500); 2 Apr 2009 02:17:34 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 3385 invoked by uid 99); 2 Apr 2009 02:17:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 02:17:34 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 02:17:33 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id DFD65234C003 for ; Wed, 1 Apr 2009 19:17:12 -0700 (PDT) Message-ID: <1937416026.1238638632912.JavaMail.jira@brutus> Date: Wed, 1 Apr 2009 19:17:12 -0700 (PDT) From: "James Fu (JIRA)" To: issues@commons.apache.org Subject: [jira] Commented: (NET-140) FTPClient listFiles returns incorrect timestamp on freshly uploaded file but corrects itself after about 15 minutes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/NET-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694869#action_12694869 ] James Fu commented on NET-140: ------------------------------ Hi Rory and Sebb, thanks for the reply! To Rory: Here's the raw output from ftp server corresponding to the file that I just uploaded: -rw-r--r-- 1 182390 eng2 91184 Apr 2 10:06 0C5F8D76F819BF060A791469835B1BF0.commons-net-ftp-2.0.jar If not using following code segments, I got display year 2008; if used, go correct year 2009. FTPClientConfig conf = new FTPClientConfig(FTPClientConfig.SYST_UNIX); conf.setLenientFutureDates(true); this.ftp.configure(conf); To Sebb: The timezone of client and ftp server are both GMT. I've both tried to set the time on client side to be ahead of server time and behind server time, but seems the same. All need to setLenientFutureDates(true) to make it display correctly. > 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.