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.
This bug was originally marked as duplicate of bug 214143, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related. Build: NetBeans IDE 7.2 RC1 (Build 201206272359) VM: Java HotSpot(TM) 64-Bit Server VM, 23.1-b03, Java(TM) SE Runtime Environment, 1.7.0_05-b05 OS: Windows 7 Stacktrace: java.lang.AssertionError: getRelativePath(R:\_project_\3-calendar(my)\cache\catalog\CatalogCacheClient\src\main\java, R:\_project_\3-calendar(my)\cache\Catalog\CatalogCacheClient\src\main\java\com\pb\crm\cache\CatalogCache.java) at org.netbeans.modules.java.source.parsing.FileObjects.getRelativePath(FileObjects.java:687) at org.netbeans.modules.java.source.parsing.FileObjects.fileFileObject(FileObjects.java:211) at org.netbeans.modules.java.source.indexing.JavaCustomIndexer.createTuple(JavaCustomIndexer.java:368) at org.netbeans.modules.java.source.indexing.JavaCustomIndexer.index(JavaCustomIndexer.java:214) at org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$2.run(Indexable.java:158) at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:259)
Created attachment 122039 [details] stacktrace
Created attachment 126970 [details] stacktrace starting NB
Created attachment 127099 [details] stacktrace created new project
Created attachment 127139 [details] stacktrace
Seems related to Utilities.toURI, Utilities.toFile as the problem appeared right after the code was rewritten to use it. I've added the logging to find out where the URL (FileObject) was un normalised. Can you please reproduce the issue with the following command line option and attach the messages.log file? The cmd line option: -J-Dorg.netbeans.modules.parsing.impl.indexing.FileObjectIndexable.level=FINEST You will need to wait until the logging propagates into the daily build, the builder will add a message into the issue and next daily build should have the logging. The request is specially for rrossi who seems to reproduce it quite easily. Thanks a lot!
jet-main f588f4ad77dc
Integrated into 'main-golden', will be available in build *201211150001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/f588f4ad77dc User: Tomas Zezula <tzezula@netbeans.org> Log: #215561:AssertionError: getRelativePath - logging
Reopening this bug based on new exception report: http://statistics.netbeans.org/exceptions/exception.do?id=639525
See comment #5
Reopening this bug based on new exception report: http://statistics.netbeans.org/exceptions/exception.do?id=639842
Read comment #5 and provide the required info then reopen.
Even it's strange the RESOLVED INCOMPLETE does not mean that the issue is fixed. It means that the reporter(s) should provide requested info and then reopen. In the past we had a keyword INCOMPLETE which was more natural and understandable, however it was changed for some to me unknown reason to RESOLVED INCOMPLETE which is strange.
Reopening this bug based on new exception report: http://statistics.netbeans.org/exceptions/exception.do?id=643286
Build 201212220001 How to reproduce: - Create a new Project - Menu|File|New Project|Java|Java Application - In the wizard, where you enter the project name, enter "TEst2" without progressing, whithout leaving this field - While the focus is in the same field, change the name to "Test2" by only replacing the upper case E with a lower case e. - Click Finish The IDE then saves important files with both the wrong "TEst2" project name AND the corrected "Test2" project name. This corrupts the project, the scanning and the error badges in the project. The resulting mess can be very confusing. The result would be data loss in case one does not know how to fix this. I had to do a case sensitive search in the project dir and both parts of the user dir (in Windows) and then edit a few files, including cached files. Very messy. See logs in exception report id #643361 classified as a duplicate of report #190758
Created attachment 129849 [details] stacktrace opening project double-checked paths: exist
Created attachment 129850 [details] stacktrace resolve missing JUnit problem, I guess it's the same problem as reported before double-checked paths: exist
In reply to comment #14: Unfortunately I am not able to reproduce it with given steps on Mac. Please can you retry it if it's reproduceable? Thanks
This looks very platform specific (case sensitivity in file names). Could you please try this on Windows?
I've did, but I have only a virtual Win XP and it also worked without any problem. Can you please retry the steps and if reproduceable attach the broken project? Thanks!
Unfortunately I cannot reproduce the steps at comment 14 on Win7
What logging parameter could I use to help pin this down - and what else? I can reproduce this reliably. I should send you my computer :)
I hope we will not need your computer :-) Good start will be the broken project, hopefully we will be able to open it and simulate the problem. Thanks!
Created attachment 129908 [details] Project and other files in zip file The attachment contains the project where all relevant files contain "Test2" and other files that contain "TEst2": userdir\var\log\messages.log, userdir\var\cache\index\segments, userdir\config\Preferences\org\netbeans\modules\projectui.properties
The attached zip contains probably a wrong project. It's a Web Project while it was reported to J2SE Application and it has correct case both in file name and metadata. Can you update it? Thanks!
Created attachment 129951 [details] Project and other files in zip file Sorry. Was wrong project as you say. The project itself is not corrupted. The files in the userdir are corrupted. Try a case sensitive search over the other files. There are possibly multiple scenarios that create this, my scenario being one of them. My computer is slow - if that is a criterion then you might have trouble reproducing this.
Can you try it with the -J-Dorg.netbeans.modules.parsing.impl.indexing.FileObjectIndexable.level=FINEST option and attach the log. It seems that there is a valid non normalized FileObject which is illegal. I don't want to add useless normalization into JavaCustomIndexer as it's expensive and it will fail later on as the IDE relies on the fact that FileObjects are normalized. Thanks!
Added even more logging ef46dd734cfd
I've added even more logging. Can you try it with the -J-Dorg.netbeans.modules.parsing.impl.indexing.FileObjectIndexable.level=FINEST -J-Dorg.netbeans.modules.parsing.impl.indexing.URLCache.level=FINEST For the second one you need to wait for build with changeset ef46dd734cfd or use the jar I am going to attach.
Created attachment 129961 [details] Build of parsing api including a new logging
Many thanks for the module file and the logging options. It is frustrating - the case does not reproduce anymore even with the old module file. I still have a copy of the userdir of the old reproducing case. There is a different exception at startup which is not shown in a dialog: org.openide.filesystems.FileStateInvalidException: File libraries-timestamps.properties cannot be found in folder org-netbeans-api-project-libraries. at org.openide.filesystems.MultiFileObject.createData(MultiFileObject.java:1202) at org.openide.filesystems.FileObject.createData(FileObject.java:1014) at org.netbeans.modules.project.libraries.LibrariesStorage.saveTimeStamps(LibrariesStorage.java:471) [catch] at org.netbeans.modules.project.libraries.LibrariesStorage.loadFromStorage(LibrariesStorage.java:205) at org.netbeans.modules.project.libraries.LibrariesStorage.initStorage(LibrariesStorage.java:228) at org.netbeans.modules.project.libraries.LibrariesStorage.getLibraries(LibrariesStorage.java:300) at org.netbeans.modules.project.libraries.LibrariesModule.run(LibrariesModule.java:61) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1477) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2071)
Integrated into 'main-golden', will be available in build *201301080001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/ef46dd734cfd User: Tomas Zezula <tzezula@netbeans.org> Log: #215561:AssertionError: getRelativePath(R:\_project_\3-calendar(my)\cache\catalog\CatalogCacheClient\src\main\java, R:\_project_\3-calendar(my)\cache\Catalog\CatalogCacheClient\src\main\java\com\pb\crm\cache\
Fixed jet-main 2de5b900d582 I've rewritten the JavaCustomIndexer not to calculate relative path. In addition to this I am invalidating FS cache when !uri.toFileObject().toURI().equals(uri). Thanks bht for cooperation!
Integrated into 'main-golden', will be available in build *201301090001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/2de5b900d582 User: Tomas Zezula <tzezula@netbeans.org> Log: #215561:AssertionError: getRelativePath(R:\_project_\3-calendar(my)\cache\catalog\CatalogCacheClient\src\main\java, R:\_project_\3-calendar(my)\cache\Catalog\CatalogCacheClient\src\main\java\com\pb\crm\cache\
*** Bug 225917 has been marked as a duplicate of this bug. ***