commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton (JIRA)" <>
Subject [jira] Updated: (IO-215) FileUtils copy methods swallow date modification failures
Date Wed, 15 Sep 2010 15:35:32 GMT


Niall Pemberton updated IO-215:

    Attachment: IO-215-copy-option.patch

I couldn't think of sensible names for new methods - for example copyFilePreserve() would
probably be confusing because copyFile(File, File) does "preserve" and it doesn't really reflect
that an exception will be thrown if not preserved - which is the difference with copyFile().
 Something like copyFileThrowExceptionIfDatesNotPreserved() isn't very pleasant.

On the "returning boolean" suggestion - it seems slightly unnatural/odd to return a boolean
from a copy method that means "dates preserved or not" - the natural meaning in my mind would
be to indicate whether a file was copied or not - for example:

if (FileUtils.copyFile(source, dest)) {
   // ?means dates preserved, not file copied?

Another idea would be to add an enum for the three types of behaviour:
    * Don't Preserve Dates
    * Preserve Dates
    * Preserve Dates and throw exception

> FileUtils copy methods swallow date modification failures
> ---------------------------------------------------------
>                 Key: IO-215
>                 URL:
>             Project: Commons IO
>          Issue Type: Bug
>          Components: Utilities
>            Reporter: Sebb
>         Attachments: IO-215-copy-option.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.

View raw message