You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by GitBox <gi...@apache.org> on 2022/09/04 16:23:25 UTC

[GitHub] [commons-io] tresf commented on pull request #377: IO-769: FileUtils copyDirectory() should not use COPY_ATTRIBUTES

tresf commented on PR #377:
URL: https://github.com/apache/commons-io/pull/377#issuecomment-1236373760

   > Notice that in the (old) Jira tickets above, two are about attributes not being copied, which we now do but this PR proposes to undo. So catch-22. Ideas?
   
   The API already offers `COPY_ATTRIBUTES` in several APIs as `CopyOptions` parameters.  Note, the current API doesn't allow the removal of the assumed `COPY_ATTRIBUTES` and if you look at the history of the StackOverflow and mailing list posts, this is often the first instinct, e.g:
   1. User doesn't get desired copy behavior
   2. Community recommends adjusting `CopyOptions`
   
   ... however the current behavior doesn't give this control to the user, despite it being the first instinct by the community, quoting:
   
   > **Gary wrote:** Use `org.apache.commons.io.FileUtils.copyFile(File, File, boolean, CopyOption...)` to exercise full control over what you want to do. Under the covers it ends up calling `java.nio.file.Files.copy(Path, Path, CopyOption...)`.
   
   So if this regression is not reverted, I'd at least advocate for an API which would make the above statement correct.  The current behavior silently adds `COPY_ATTRIBUTES`, which removes the ability to control this flag.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org