You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (JIRA)" <ji...@apache.org> on 2011/07/06 15:07:16 UTC

[jira] [Created] (WICKET-3875) Clear Files.remove() behavior

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


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

        

[jira] [Resolved] (WICKET-3875) Clear Files.remove() behavior

Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov resolved WICKET-3875.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 1.5-RC6

The proposed patch is committed with r1145102.

> 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
>             Fix For: 1.5-RC6
>
>         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

        

[jira] [Updated] (WICKET-3875) Clear Files.remove() behavior

Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
     [ 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