On Thu, Jul 7, 2011 at 1:30 PM, Peter Ertl <[email protected]> wrote: > If someone calls Files#remove(File) with a folder I would throw an > IllegalArgumentException but not just erase the whole folde. People could see > a potential similarity between java.io.File#delete() and Files#remove() and > be very surprised when this method suddenly erases a folder with 20000 files > below it. > > Instead I would prefer something like Files#removeFolder(File folder). Just > erasing a directory recursively with an innocent-sounding function like > 'remove' seems to dangerous for me. Agree. > > We could also rename Files#remove(file) to Files#removeFile(file). > > In case there's demand for it, I could also imagine Files#remove(IFileVisitor > visitor, boolean recursive) to selectively delete files using a file visitor > that returns 'true' if the file should be erased. > > --- boolean IFileVisitor#shouldDeleteFile(File file) > > So it would be very easy to delete all files with *.backup extension or files > older that a certain age, just to mention an example. No such demand for now. > > I am against reporting that the file has been deleted when it fact is has > just been scheduled for deletion on JVM exit. The JVM exit can happen very, > very late (e.g. several months on a production server). Since the program > eventually relies on the successful deletion of a file that is still there > this could cause some very ugly problems which are hard to track (since the > file still disappears and so the problem when you restart the JVM). Currently it reports 'false', i.e. the file is not deleted. It logs a warning saying that the file cannot be deleted and is scheduled for deletion at exit time. > > Do you know if the long wait on windows comes from file locking or access > problems? Knowing more about the problem would help to find a better solution. There is a link to bugs.sun.com in 1.4.x code but Oracle broke the link without redirect... On heavy load NTFS can just reject your request for deletion. Most of the times trying few millis later succeeds. Taking into account 'System.gc()' that was used I can imagine that the file cannot be removed because there is non-finalized handle to it. Calling .gc() will run the finalizers and eventually release the handle. But calling gc() may stop the work of other threads as well as we noticed. > > Cheers > Peter > > Am 07.07.2011 um 11:48 schrieb Martin Grigorov: > >> 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
