When trying to check why is delete of file blocked when scan in progress, we've found problems during delete action.
1. Delete action blocked throughout scanning
SafeDeleteAction intercepts common delete action and needs to run userActionTask in infrastructure, which is blocked by scan.
2. Delete action is slow when deleting bunch of files
Again, refactoring needs to run several user action tasks - exactly said NodeToFileObjectTask. (task per file)..
3. Other refactoring plugins are also initialized, e.g. HibernateRefactoring, SpringBeansPlugin.
All these initialization can be useful when SafeDeleteRefactoring, but when plain delete, the computation just wastes time. For example, when deleting
bunch of files containing at least one non-java file, the refactoring isn't used and the deletion is straightforward.
Perhaps there is a way how to optimize the code, but we are more interesting in a way how to postpone refactoring initialization until user decides about safe
delete. For better understanding, I will provide profiler snapshot of current behavior.
Created attachment 84479 [details]
Created attachment 84761 [details]
*** This issue has been marked as a duplicate of 134716 ***
Integrated into 'main-golden', will be available in build *200909181401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Pavel Flaska <email@example.com>
Log: #168267: Do not block delete when scan in progress.