You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Sebb (JIRA)" <ji...@apache.org> on 2010/09/18 01:41:32 UTC

[jira] Issue Comment Edited: (IO-215) FileUtils copy methods swallow date modification failures

    [ 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.