Hello Stefan,
On 26/06/25 5:16 pm, Stefan Bodewig wrote:
> On 2025-06-26, Jaikiran Pai wrote:
>
>> However on Windows we are seeing a large number of test failures. I
>> looked into those failures and those all relate to the "heads up"
>> section in your mail about
>> https://jdk.java.net/25/release-notes#JDK-8355954. In the Ant
>> testsuite there are several tests which attempt a
>> java.io.File.delete() on a read-only file. Until Java 25, that call
>> would delete the file.
>
>> As noted in the linked change, that's no longer the case by default in
>> Java 25. I manually updated the Ant testsuite to set the newly
>> introduced -Djdk.io.File.allowDeleteReadOnlyFiles system property to
>> true and that got all those tests to pass on Windows too.
>
> Maybe we should change the tests, rather than set the system property?
Yes, that's an option too. For reference, this is the run against
Windows which shows these failures
https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Windows%20(latest%20EA%20JDK)/74/
That failure number is exaggerated by the fact that several of these
failures are due to a side effect of few tests creating a read-only file
then failing to delete it. Subsequent tests then use that same file
(through the "touch" task) and check whether it's writable and notice
that it isn't and that causes a lot of those tests to fail.
> Is the file read-only on non-Windows platforms as well?
In our tests, yes.
> To me the description of the change doesn't say what the behavior is
on other
> platforms. Is Windows the only one that now will not delete read-only
> files - or is it the only one where read-only files would have been
> removed prior to Java 25?
On *nix platforms a File.delete() completes successfully (and returns
true) for a read-only file, because the underlying *nix platform allows
that. So it's only on Windows where the File.delete() will no longer
succeed (and will returns false) against these read-only files.
Previously, before https://bugs.openjdk.org/browse/JDK-8355954 got fixed
recently, (only) on Windows the internal implementation of the JDK was
removing the read-only attribute from the file before doing the delete,
which is why the delete would succeed and we didn't notice this issue.
> Also we could modify FileUtils.tryHardToDelete to remove the read-only
> flag if we feel this is something that may hit Ant's users. After all it
> has bitten our own testsuite.
I haven't given it a deeper thought. I think once we take care of these
antunit test failures in the testsuite, then it might give us a better
picture if there are actual scenarios where some code intentionally
wants to detail a read-only file. If there exists such a use case, then
since the JDK is already providing a way to delete such files (through
the use of this system property), then we would need to evaluate if we
still want to add some code in FileUtils.tryHardToDelete or advice users
to use that system property instead.
In the next few days I will go over these tests to see how we can
address these issues and if the usage of the new system property can be
avoided.
-Jaikiran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
