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.
Build: NetBeans IDE 7.0 Beta 2 (Build 201102140001) VM: Java HotSpot(TM) 64-Bit Server VM, 19.1-b02, Java(TM) SE Runtime Environment, 1.6.0_24-b07 OS: Windows 7 Stacktrace: java.io.FileNotFoundException at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObj.getInputStream(FileObj.java:152) at org.openide.filesystems.FileUtil.copyFileImpl(FileUtil.java:730) at org.openide.filesystems.FileObject.copy(FileObject.java:129) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.copy(BaseFileObj.java:241) at org.openide.filesystems.FileObject.copy(FileObject.java:124) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.copy(BaseFileObj.java:241)
Created attachment 107944 [details] stacktrace
IOException throw when FS called from org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation.doMoveProject(DefaultProjectOperationsImplementation.java:488) DefaultProjectOperationsImplementation needs to be ready for IOExceptions
The latest report is from DefaultProjectOperationsImplementation, which handles IOException's - it calls attachLocalizedMessage and reports them, which ought to suffice to show a "polite" error dialog without triggering the exception reporter. (I just tried patching doMoveProject to throw new FileNotFoundException() unconditionally and this is what happens, so I cannot think what else DPOI should be doing; fatal errors during an explicitly requested operation have to be reported in the UI somehow.) The previous exceptions in the log file indicate that something is badly wrong with the reporter's file system, though it is hard to guess what (some Windows-specific problems). Oddly, the stack trace reported here is not present in the log file. All the previous reports are from PasteAction, not involving the project system. In that case DataFolder.handleCopy is catching IOException for each child and reporting it, even though the whole method is permitted to throw IOException - is this is a mistake? FileObj.getInputStream should probably be including the file name in the detail message for purposes of diagnosis, since it is not obvious why a directory move should be failing in the _read_ side of a deeply nested call to copy - normally you would expect a copy to fail during the _write_. (If the folder can be atomically moved using File.renameTo then I would expect that masterfs would have done so and these stack traces would never be seen, but I guess Windows does not support this and forces a recursive-copy-and-delete? Or perhaps it is supported generally but not across drives, etc.)
ergonomics#2364e3016f98
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/2364e3016f98 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #198082: java.io.FileNotFoundException at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObj.getInputStream More logging to find out what is weird while moving subtrees