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.
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.
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).
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.
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
