alternatively, if we do not recurse we can just do what it does now, when any file in folders fails - wait 100ms and try to delete the folder again.
-igor On Thu, Jul 7, 2011 at 8:38 AM, Martin Grigorov <[email protected]> wrote: > This is something like org.apache.wicket.util.file.FileCleaningTracker > which is used to delete the uploaded files, but unfortunately it > doesn't support folders as well. > > On Thu, Jul 7, 2011 at 5:31 PM, Igor Vaynberg <[email protected]> wrote: >> 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 >>> >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com >
