This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Now RemoteFS.getMimeType can not be interrupted. It tries to read 4K from each file in the directory, and does not stop until this is done. This can make some file choosers (ones that use filtering by mime type) slow and user can not work this around via pressing "Up" or "Home" button. This seems to be one of the issues that cause CR 22187945.
This happens if user selects a binary (since in this case filtering is based on MIME type). The stack is "pool-3-thread-1" at org.netbeans.modules.remote.impl.fs.RemoteDirectory.getMagic(RemoteDirectory.java:1619) at org.netbeans.modules.remote.impl.fs.RemoteFileObjectBase.getMagic(RemoteFileObjectBase.java:370) at org.netbeans.modules.remote.impl.fs.RemoteFileObject.getInputStream(RemoteFileObject.java:387) at org.openide.filesystems.MIMESupport$CachedFileObject.getInputStream(MIMESupport.java:402) at org.netbeans.modules.openide.filesystems.declmime.FileElement$Type.accept(FileElement.java:586) at org.netbeans.modules.openide.filesystems.declmime.FileElement$Type.access$300(FileElement.java:156) at org.netbeans.modules.openide.filesystems.declmime.FileElement.resolve(FileElement.java:99) at org.netbeans.modules.openide.filesystems.declmime.MIMEResolverImpl$Impl.findMIMEType(MIMEResolverImpl.java:450) at org.openide.filesystems.MIMESupport$CachedFileObject.resolveMIME(MIMESupport.java:371) at org.openide.filesystems.MIMESupport$CachedFileObject.getMIMEType(MIMESupport.java:312) at org.openide.filesystems.MIMESupport.findMIMEType(MIMESupport.java:136) at org.openide.filesystems.FileUtil.getMIMEType(FileUtil.java:1341) at org.netbeans.modules.cnd.utils.MIMESupport.getBinaryFileMIMEType(MIMESupport.java:132) at org.netbeans.modules.cnd.utils.MIMESupport.getBinaryFileMIMEType(MIMESupport.java:150) at org.netbeans.modules.cnd.utils.filters.AllBinaryFileFilter.mimeAccept(AllBinaryFileFilter.java:77) at org.netbeans.modules.cnd.utils.FileAndFileObjectFilter.accept(FileAndFileObjectFilter.java:65) at javax.swing.JFileChooser.accept(JFileChooser.java:1696) at org.netbeans.modules.remote.api.ui.FileNode.loadChildren(FileNode.java:143) at org.netbeans.modules.remote.api.ui.FileChooserUIImpl$UpdateWorker.validate(FileChooserUIImpl.java:3114) at org.netbeans.modules.remote.api.ui.FileChooserUIImpl$UpdateWorker.run(FileChooserUIImpl.java:3146) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:265) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:747)
CR 22187945 is fixed differently. This bug is still valid, but after the CR is fixed I know no particular situation that harms user. I'm even not sure it worths P3 priority.