> > Under the covers it ends up calling *java.nio.file.Files.copy(Path, Path, > CopyOption...)*.
Sure, but from what I'm reading, it's adding CopyOptions that no one asked for and is not in alignment with how NIO works, so this statement is a bit misleading. I think this is the problematic line: https://github.com/apache/commons-io/blob/f22a4227401855ecbfdf8184bbe37275c3aeb5c3/src/main/java/org/apache/commons/io/FileUtils.java#L701 >From what I'm reading, toggling off "preserveFileDate" will inadvertently and unobviously fix this, but at this point. This fix seems like undesired, undocumented and prone-to-break-later behavior, at least for Windows environments. I'm curious what reasoning was used to associate a file's modified date with the rest of its attributes. Perhaps this was a backward-compat shortcut to maintain the modified date using the new NIO API? Regardless, this introduces permissions changes which can and will break standard file copy operations for environments which expect inherited permissions, e.g. Windows. Ideally, the file modified date could stay without clobbering the default NIO behavior. For now a viable workaround is: FileUtils.copyDirectory(folder, dest, false /* <--- change to FALSE */); ... hjowever this does have the disadvantage of losing timestamp information, which is still a regression, albeit smaller.
