Initial commit(s): https://github.com/apache/commons-io/compare/master...tresf:commons-io:attributes
- It still needs human testing on many platforms (I plan to perform these) - Unit tests have been added (need to be human-verified before accepting them as passing) - I'd like to know why there are two separate function calls for preserving the last modified date (I've added this question in a TODO in the patch) https://github.com/apache/commons-io/blob/8e072110e9d6ed0f81039929f4a81818c515439c/src/main/java/org/apache/commons/io/FileUtils.java#L2854-L2858 Any/all feedback is welcome. If the granular approach of "setTimes()" hepler (setting creation + modified + access times) is too much of a change, the function can be reverted or simplified. - tres.finocchi...@gmail.com On Mon, Aug 22, 2022 at 11:34 AM Tres Finocchiaro < tres.finocchi...@gmail.com> wrote: > > what I'd expect as a new user of Commons IO > > > I think it's safe to say, at least on Windows, the default OS behavior is > what 99% of people will want default in a copy utility; copying a file to a > destination nearly always warrants the destination permissions, especially > when the ACLs for Windows are so specific and rather tricky to manipulate > after the fact. > > On MacOS, my results are identical, in zsh and bash, a file created in > user-space, but copied (NOT moved) to a root-owned space will inherit the > "root" permissions upon copy (consistent with old behavior, not new > behavior). > > On Ubuntu, my results are identical as well: In bash, a file created in > user-space, but copied (NOT moved) to a root-owned space will inherit the > "root" permissions upon copy (consistent with old behavior, not new > behavior). > > In my opinion, the utility is not useful without this behavior toggled > back on by default. Otherwise, NIO with a walktree would accomplish this > task instead, so by NOT reverting this change, the project is knowingly > abandoning this API (or making a decision to keep an un-intuitive and > confusing API workaround. But I've stated this before, so I will digress > in my opinion, it's not really what's being discussed right now. > > Perhaps a better, more objective argument is that for 16 years, the > behavior was the same, only to be changed for (less than) two years. In > the case of my project, this was unnoticed as we often wait before > upgrading library versions due to API changes. (however when Log4J > vulnerabilities in past years started reaching our clients, we've been > trying to take a more responsible approach) > > Since this is a "users" list, I would love to hear opinions that are less > influenced. :) > > > Another concern is that for changes we should have tests that will avoid >> future regressions and also clearly document why the test exists so that >> the tests are not also changed inadvertently, > > > I have been thinking about this as well. I hope I can receive some > guidance on this, however, I would also like to set some scope that I would > expect: > > - Javdoc comments updated to be more concise only for the APIs that > are modified > - I can receive some assistance from experienced devs on writing the > unit tests. I could run platform-specific shell commands or use NIO > features, but to test this on Windows would need some form of Windows CI > host, so hopefully I can get some guidance on GitHub for this. > > I do understand there's a chance the team will reject this PR for reasons > beyond my control, but I also hope that my sentiments about the usefulness > of this API are weighed, since I believe this API will become less > attractive for new developers if not corrected to its old behavior. :) >
