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.
There a lots of messages like the following in console and message log: INFO: fs_server reports zero errno; treating as file not found: Error 0: /tmp/tmp.OFaOzl/subdir_1 It seems it's easier to reproduce this on Solaris than on Linux (not sure this takes place on Linux at all)
I still do not know the root cause, but in cases I was able to easily reproduce the control went through the following stack: at org.netbeans.modules.remote.impl.fs.server.FSSUtil.createIOException(FSSUtil.java:115) at org.netbeans.modules.remote.impl.fs.server.FSSTransport.createIOException(FSSTransport.java:195) at org.netbeans.modules.remote.impl.fs.server.FSSTransport.stat_or_lstat(FSSTransport.java:172) at org.netbeans.modules.remote.impl.fs.server.FSSTransport.stat(FSSTransport.java:120) at org.netbeans.modules.remote.impl.fs.RemoteFileSystemTransport.stat(RemoteFileSystemTransport.java:132) at org.netbeans.modules.remote.impl.fileoperations.spi.FileOperationsProvider$FileOperations.isDirectory(FileOperationsProvider.java:140) at org.netbeans.modules.remotefs.versioning.spi.FileProxyProviderImpl$FileOperationsImpl.isDirectory(FileProxyProviderImpl.java:121) at org.netbeans.modules.versioning.core.api.VCSFileProxy.isDirectory(VCSFileProxy.java:253) at org.netbeans.modules.versioning.core.filesystems.VCSFilesystemInterceptor.getInterceptor(VCSFilesystemInterceptor.java:456) at org.netbeans.modules.versioning.core.filesystems.VCSFilesystemInterceptor.deletedExternally(VCSFilesystemInterceptor.java:270) at org.netbeans.modules.remotefs.versioning.spi.FilesystemInterceptorProviderImpl$FilesystemInterceptorImpl.deletedExternally(FilesystemInterceptorProviderImpl.java:141) at org.netbeans.modules.remote.impl.fs.RemoteDirectory.fireDeletedEvent(RemoteDirectory.java:1324) at org.netbeans.modules.remote.impl.fs.RemoteDirectory.updateChildren(RemoteDirectory.java:1262) at org.netbeans.modules.remote.impl.fs.RemoteDirectory.getDirectoryStorageImpl(RemoteDirectory.java:1112) at org.netbeans.modules.remote.impl.fs.RemoteDirectory.refreshDirectoryStorage(RemoteDirectory.java:521) at org.netbeans.modules.remote.impl.fs.RemoteDirectory.refreshImpl(RemoteDirectory.java:1586) at org.netbeans.modules.remote.impl.fs.RefreshManager$RefreshWorker.run(RefreshManager.java:109) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1423) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
When processing external remove, VCS stuff tries to understand whether a file is (was!) a directory - and asks remote host about that (which finally goes to fs_server). This isn't a root cause, but this is exactly the situation that leads to these traces. And this wastes time in vain since we *just* discovered that the file has been removed - so remote system will *not* be able to answer. Fixed in http://hg.netbeans.org/cnd-main/rev/254572920e69 Also added a bit more trace in http://hg.netbeans.org/cnd-main/rev/fa56caafd310
Here is the fix that fixes the root cause http://hg.netbeans.org/cnd-main/rev/f478c153ea36
Integrated into 'main-silver', will be available in build *201407250001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/fa56caafd310 User: Vladimir Kvashin <vkvashin@netbeans.org> Log: a little bit more trace for #245926 - A lot of "fs_server reports zero errno..." warnings in console