Hi,
Related to https://issues.apache.org/jira/browse/WICKET-3875 I want to
discuss the behavior of Files#remove(File).
In 1.4.x this method tries java.io.File#delete() and if this doesn't
succeed then it calls System.gc(), waits for 100ms and tries again.
According to the javadoc of the method this is done
because of bug in Windows.
There are two problems:
- file.delete() will not delete the file if it is a directory with files
- System.gc() is bad thing in multiuser environment (web)
In 1.5 I removed "System.gc()" recently because we saw it in our perf tests.
For the Windows bug I reworked the code to try at most 10 times to
delete the file with delay between of 100ms. At the end if the file
still cannot be deleted then I schedule it for deletion at the end of
the process :
logger.warn("Cannot delete file '{}' for unknown reason. The file will
be scheduled for deletion at JVM exit time.", file);
file.deleteOnExit();
Now I see that my solution is not optimal because it will wait too
long if the user code tries to remove a non-empty folder or the
current user has no permissions to delete the file.
My questions to you are:
1) should we make Files.remove() able to deal with folders ? For
example list the content and recourse.
2) do you have better solution for the Windows bug? Because now this
method will wait A LOT if the user pass a folder with many files and
it has no permissions to delete them.
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
