[
https://issues.apache.org/jira/browse/WICKET-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov updated WICKET-3875:
------------------------------------
Attachment: WICKET-3875.patch
Implement async removal of files via commons-upload FileCleaningTracker.
API Break: renamed org.apache.wicket.util.file.IFileUploadCleaner to
org.apache.wicket.util.file.IFileCleaner since it is not used just for file
uploads anymore. This class has been introduced in 1.5 so I don't expect many
users of it.
> Clear Files.remove() behavior
> -----------------------------
>
> Key: WICKET-3875
> URL: https://issues.apache.org/jira/browse/WICKET-3875
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 1.5-RC5.1
> Reporter: Martin Grigorov
> Assignee: Martin Grigorov
> Attachments: WICKET-3875.patch
>
>
> Currently org.apache.wicket.util.file.Files.remove(File) can remove just
> normal files.
> I just found that it is called with a folder parameter and since
> File.delete() cannot delete non-empty directory it starts waiting for 100ms
> and trying again 10 times.
> This retry strategy is there for problems in Windows systems where the first
> removal attempt may fail and few millis later may succeed.
> We should clear Files.remove() behavior because now it wastes 10*100ms trying
> to delete non-empty folder.
> If I make the method able to delete files via recursion then it can almost
> block a thread if for some reason the files inside cannot be deleted (e.g. no
> permissions). In such case it will wait 1sec for each file.
> The other solution is to check all callers and make sure that all callers
> always pass a file (not a folder).
> The specific problem that I found is that DiskDataStore tries to delete
> org.apache.wicket.settings.IStoreSettings.getFileStoreFolder() but this
> folder contains file with name "data" inside and fails.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
