Hi Tres, Please create a PR on GitHub so we can see build results in all the OSs and Java versions we test there.
Gary On Fri, Aug 26, 2022, 01:50 Tres Finocchiaro <tres.finocchi...@gmail.com> wrote: > 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. :) > > >
