Gradle
  1. Gradle
  2. GRADLE-2244

Cleaning should be more robust on Windows

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.1-rc-1

      Description

      I'm seeing this on windows when the indexer is on.

      It manifests as java.io.IOException: Unable to delete file/directory, and then a subsequent clean will succeed.

      We could cater for this by noting that a particular operation failed, and then retrying it again at the end or after some time.

        Activity

        Hide
        Szczepan Faber
        added a comment -

        If we develop this feature they will probably have to remember all undeletable dirs. So I'd vote to also improve the error message to include the list of all dirs that the build could not delete at clean. This would be very useful in windows.

        Show
        Szczepan Faber
        added a comment - If we develop this feature they will probably have to remember all undeletable dirs. So I'd vote to also improve the error message to include the list of all dirs that the build could not delete at clean. This would be very useful in windows.
        Hide
        Luke Daley
        added a comment -

        Szczepan,

        I'm inclined not to include this. The reason is that it actually makes the logic non trivially more complex, and would only really help in the situation where someone has asked to delete multiple roots which is rare. Typically the delete is just operating on the “build dir”.

        Show
        Luke Daley
        added a comment - Szczepan, I'm inclined not to include this. The reason is that it actually makes the logic non trivially more complex, and would only really help in the situation where someone has asked to delete multiple roots which is rare. Typically the delete is just operating on the “build dir”.
        Hide
        Luke Daley
        added a comment -

        After some research, it appears that this may be due to a bug in the Windows JDKs (incl IBM). Ant uses a strategy of forcing a GC after a failed delete and then waiting a small amount of time. Given that this appears to be a successful strategy for Ant, we have adopted it.

        Show
        Luke Daley
        added a comment - After some research, it appears that this may be due to a bug in the Windows JDKs (incl IBM). Ant uses a strategy of forcing a GC after a failed delete and then waiting a small amount of time. Given that this appears to be a successful strategy for Ant, we have adopted it.

          People

          • Assignee:
            Luke Daley
            Reporter:
            Luke Daley
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: