Return-Path: Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: (qmail 59918 invoked from network); 17 Sep 2010 23:41:57 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 17 Sep 2010 23:41:57 -0000 Received: (qmail 86567 invoked by uid 500); 17 Sep 2010 23:41:57 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 86494 invoked by uid 500); 17 Sep 2010 23:41:56 -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 86485 invoked by uid 99); 17 Sep 2010 23:41:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Sep 2010 23:41:56 +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.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Sep 2010 23:41:54 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o8HNfWGa022040 for ; Fri, 17 Sep 2010 23:41:32 GMT Message-ID: <14277259.263431284766892443.JavaMail.jira@thor> Date: Fri, 17 Sep 2010 19:41:32 -0400 (EDT) From: "Sebb (JIRA)" To: issues@commons.apache.org Subject: [jira] Issue Comment Edited: (IO-215) FileUtils copy methods swallow date modification failures In-Reply-To: <1075025228.1250704275123.JavaMail.jira@brutus> 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/IO-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910850#action_12910850 ] Sebb edited comment on IO-215 at 9/17/10 7:39 PM: -------------------------------------------------- OK, I wondered about maintaining a count. Arguably more useful than the details of the first failed file, but would be nice to have the total count (and perhaps the first file) as well. But that can be tweaked later if necessary without changing the API. was (Author: sebb@apache.org): OK, I wondered about maintaining a count. Arguably more useful than the details of the first failed file, but would be nice to have the total count as well. But that can be tweaked later if necessary without changing the API. > FileUtils copy methods swallow date modification failures > --------------------------------------------------------- > > Key: IO-215 > URL: https://issues.apache.org/jira/browse/IO-215 > Project: Commons IO > Issue Type: Bug > Components: Utilities > Reporter: Sebb > Attachments: IO-215-copy-option-v3.patch, IO-215-copy-option-v4.patch > > > FileUtils.doCopyDirectory(..) and .FileUtils.doCopyFile(..) both call the setLastModified() method, but fail to check if it succeeded or not. > Surely if the caller has asked for the date to be preserved, failure to do so should be reported somehow? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.