the reason to fail is what bothers me. if the current process has no permissions to delete this file then this delete operation will "block" forever even if we try N attempts to delete the file/folder then trying to delete a folder with hundreds of files will slow down again
or you mean : try N times x 100ms for the folder and give up ? On Thu, Jul 7, 2011 at 5:54 PM, Igor Vaynberg <[email protected]> wrote: > 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 >> > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
