The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
If a custom implementation of FileSystemView forwarding any calls to the COM thread from its synchronized methods, is set, it causes a deadlock.
Almost all Win32ShellFolder2 methods can produce deadlock. E.g. listFiles, getDisplayName, getFolderType, isFileSystem, isDirectory isHidden and many other.
ComThread should be used ONLY in our classes. We should avoid invocation of external code (like FileSystemView implementation) from ComThread. The fix of this CR is moving invocations of FileSystemView from ComThread to another thread. I also fixed here synchronized methods in Win32ShellFolder2, because it's another cause of deadlock.
Avoid invocation of Win32ShellFolder2's methods forwarding their execution to the COM thread, from within custom FileSystemView's synchronized methods. For example, use getAbsolutePath() instead of getAbsoluteFile().
Synchronized methods of the custom FileSystemView can be invoked from both EDT and COM threads. Logically, it's the single control flow, but from the security subsystem's point of view, it's not allowed to enter a synchronized method from the COM thread till another synchronized method invoked from the EDT, is finished.