have a background daemon thread handles this. it will queue up files that cannot be deleted and keep trying in the background.
if the folder is passed in and any file in it fails to be deleted queue the folder itself again, not the individual files - ie do not make the call to delete subfolders and files recursive. -igor On Thu, Jul 7, 2011 at 2:48 AM, Martin Grigorov <[email protected]> wrote: > 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 >
