sometimes code wants to block until something is deleted. so we should probably have
deleteSynchronously(file, duration max) and deleteAsynchronously(file) -igor On Thu, Jul 7, 2011 at 8:58 AM, Martin Grigorov <[email protected]> wrote: > 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 >
