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

Reply via email to